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delivery  of  the  system  to  meet  user  schedules  resulted 
in  highly  unreliable  equipment  being  used  in 
development  efforts.  A  significant  adverse  impact  on 
user  project  costs  and  schedules  resulted. 
Examination  of  the  standard  minicomputer  acquisition 
fosters  a  number  of  recommendations  for  future 
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GLOSSARY 


AADC  -  All  Applications  Digital  Computer 

ADD  -  Alphanumeric  Display  Device 

ADP  -  Automatic  Data  Processing 

APE  -  Advanced  Production  Engineering  Model  -  a   militarized 

prototype 
CDC  -  Control  Data  Corporation 
CMTU  -  Cartridge  Magnetic  Tape  Unit 
CNM  -  Chief  of  Naval  Material 
CNO  -  Chief  of  Naval  Operations 

COMNAVELEX  -  Commander,  Naval  Electronic  Systems  Command 
CVTSC  -  Carrier  Tactical  Systems  Center 
DCAS  -  Defense  Contract  Administration  Service 
DEC  -  Digital  Equipment  Corporation 
DMA  -  Direct  Memory  Access 
DPS  -  Data  Processing  System 
DRG  -  Design  Review  Group 
ESA  -  Externally  Specified  Addressing 

FCDSSA  -  Fleet  Combat  Direction  Systems  Software  Activity 
FDM  -  Functional   Demonstration   Model   -   a  non-militarized 

prototype 
GFCS  -  Gun  Fire  Control  System 
GFE  -  Government  Furnished  Equipment 
IBM  -  International  Business  Machines  Corporation 
ILS  -  Integrated  Logistics  Support 
I/O  -  Input/Output 
IOC  -  Input/Output  Controller 

ISADC  -  Interim  Standard  Airborne  Digital  Computer 
LSI  -  Large  Scale  Integration 

MATHPAC  -  Plug-in   module   of   floating-point,  trigonometric 
and  hyperbolic  functions  implemented  in  microcode 


MICROGROWTH  -  Plug-in  module  of  user  specified  microprograms 

MOS  -  Metal  Oxide  Semiconductor 

MSI  -  Medium  Scale  Integration 

MTBF  -  Mean  Time  Between  Failures 

MTTR  -  Mean  Time  To  Repair 

NAFI  -  Naval  Avionics  Facility,  Indianapolis 

NAVAIR  -  Naval  Air  Systems  Command 

NAVELEX  -  Naval  Electronic  Systems  Command 

NAVMACS  -  Naval  Message  Address  Communications  System 

NAVMAT  -  Naval  Material  Command 

NAVORD  -  Naval  Ordnance   Systems   Command   -   combined  with 

NAVSHIPS  to  form  NAVSEA 
NAVSEA  -  Naval   Sea   Systems   Command   -  formed  by  combining 

NAVORD  and  NAVSHIPS 
NAVSEC  -  Naval  Systems  Engineering  Center 
NAVSHIPS  -  Naval   Ships   Systems   Command   -   combined   with 

NAVORD  to  form  NAVSEA 
NELC  -  Naval  Electronics  Laboratory  Center 
NESEC  -  Naval  Electronic  Systems  Engineering  Center 
NTDS  -  Naval  Tactical  Data  System 
OMB  -  Office  of  Management  and  Budget 
O&MN  -  Operations  and  Maintenance  Navy  Appropriation 
OPEVAL  -  Operational  Evaluation 
OSD  -  Office  of  the  Secretary  of  Defense 
QA  -  Quality  Assurance 
RAM  -  Random  Access  Memory 
RDT&EN  -  Research,   Development,   Test   and   Evaluation  Navy 

Appropriation 
REHSON  -  Reconnaissance   Electronic   Warfare   Systems  Office 

Navy 
RFP  -  Reguest  for  Proposals 
ROM  -  Read-Only-Memory 
SECDEF  -  Secretary  of  Defense 
SSA  -  Source  Selection  Authority 
SSAC  -  Source  Selection  Advisory  Council 
SSEB  -  Source  Selection  Evaluation  Board 


TADSO  -  Tactical    Digital    Systems   Office  of   the   Naval 

Material  Command 
TADSTAND  -  Tactical  Digital  Standard 
TALOS  -  long-range ,  surface-to-air  missile 
TARTAR  -  short-range,  surface-to-air  missile 
TECHEVAL  -  Technical  Evaluation 

TERRIER  -  intermediate-range,  surface-to-air  missile 
TTL  -  Transistor-Transistor  Logic 
ONIVAC  -  ONIVAC  Defense   Systems   Division   of   Sperry-Rand 

Corporation 
WCS  -  Writable  Control  Store 
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I.   INTRODUCTION 


A.   THESIS  OBJECTIVE 


In  1972  the  Navy  began  procurement  of  a  small  digital 
computer  which  was  to  be  a  standard  minicomputer  for 
tactical  system  applications.  That  standard  minicomputer 
was  later  designated  the  AN/UYK-20(V)  Data  Processing 
System. 

The  acquisition  strategy  employed   and  the  resulting 

events  of  the  first  three  years  of  production  caused  great 

concern   among  project  managers  who  were  required  to  use  the 
standard  minicomputer. 

At  least  one  user  project  manager  believed  that  an 
objective  look  at  the  standard  minicomputer  acquisition  was 
necessary  to  prevent  recurrence  of  those  events  which 
adversely  impacted  on  the  development  of  tactical  systems. 

It  is  the  objective  of  this  thesis  to  examine  the 
standard  minicomputer  acquisition  process,  to  evaluate  the 
system  in  light  of  user  needs  and  1972  state-of-the-art,  to 
identify  those  events  which  contributed  to  the  adverse 
impact  of  the  standard  minicomputer  on  development  efforts, 
and  to  offer  some  recommendations  for  future  acquisitions  of 
standard  tactical  digital  processors. 


METHODOLOGY 
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In  order  to  obtain  information  about  minicomputers  in 
general  and  the  AN/UYK-20 (V)  Data  Processing  System  in 
particular,  a  literature  search  was  conducted.  Pertinent 
references  are  listed  at  the  end  of  the  thesis. 

To  obtain  a  complete  and  objective  picture  of  the 
acquisition  process  it  was  then  necessary  to  contact 
personnel  at  all  levels  in  user  project  organizations  and 
also  personnel  in  the  standard  minicomputer  project 
organization.  The  following  types  of  activities  were 
contacted  to  obtain  information: 

*  Navy  field  activities  -  responsible  for  assembly, 
checkout,  delivery  and  maintenance  of  tactical 
systems  hardware  and  software. 

*  Navy  laboratories  -  responsible  for  certain  aspects 
of  tactical  system  development  and  testing. 

*  Private  contractors  -  responsible  for  hardware  and 
software  development  of  tactical  systems  under 
contract  to  Navy  project  offices. 

*  Navy  project  offices  -  responsible  for  management  of 
the  acquisition  of  tactical  systems  utilizing  UYK-20 
as  a  system  component. 

Additional  information  was  obtained  by  attending  two 
AN/UYK-20  User's  Group  meetings.  A  minimal  amount  of 
laboratory  experience  was  gained  on  the  OYK-20  itself. 
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II.   IDENTIFICATION  OF  THE  NEED  FOR  A  STANDARD  MINICOMPUTER 


The  J\96Q,s  saw  the  first  successful  employment  of  a 
general  purpose  digital  computer  in  a  shipboard  tactical 
system.  This  event  precipitated  the  introduction  of  a  large 
number  of  shipboard  computers  into  the  Navy  inventory 
manufactured  by  several  different  companies  with  slightly 
different  capabilities.  Some  of  these  computers  are  listed 
below.  Others  existed,  particularly  in  avionics 
applications. 


Computer 

MK  74 

MK  76 

MK  77 

MK  86 

AN/USQ-17 

AN/USQ-20 

CP642 

CP642A 

CP642B 

AN/OYK-7 

AN/SIA-12 

AN/UTK-15(V) 

CP890 

AN/OYK-12 (V) 


Cognizant 
tm 


NAVORD 

NAVORD 

NAVORD 

NAVORD 

NAVSEC 

NAVSEC 

NAVSEC 

NAVSEC 

NAVSEC 

NAVSEC 

NAFI 

NAVSEC 

NAVSHIPS 

NAVSHIPS 


Application 

TARTAR  Missile  System 

TERRIER  Missile  System 

TALOS  Missile  System 

Gun  Fire  Control  System 

NTDS 

NTDS 

NTDS 

NTDS 

NTDS 

NTDS 

Communications 

General  Purpose 

Navigation 

General  Purpose 


This  proliferation  of  tactical   processors   created  the 
following  types  of  problems: 

*  Small  and  uneconomical  procurement  programs. 
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*  Untenable  material  and  logistics  support  posture. 

*  Increased  scope  of  personnel  training  requirements. 

*  System  interface  and  integration  problems. 

*  Software  incompatibility. 

*  Proliferation  of  support  software. 

Recognition  of  these  problems  prompted  the  Chief  of 
Naval  Operations  (CNO)  to  direct  the  Chief  of  Naval  Material 
(CNM)  to  develop  a  standard  general  purpose  computer  for 
shipboard  and  shore  applications.  In  August  1971,  CNM 
created  the  Tactical  Digital  Systems  Office  (TADSO) 
(MAT-09Y)  to  carryout  this  directive.  Figure  1  shows  the 
position  of  TADSO  in  the  NAVMAT  organization  as  of  January 
1975.  The  chart  illustrates  that  the  Director  of  TADSO  was 
in  an  influential  postition,  reporting  directly  to  the  Vice 
Chief  of  Naval  Material.  MAT-09Y  has  traditionally  been  a 
Rear  Admiral. 

CNM,  by  reference  1,  described  the  scope  of  TADSO 
efforts: 

"(1)   Inter-and  intra-  platform   compatibility   of  all 
tactical  digital  systems  and  equipment. 

(2)  Standardization  of  tactical  digital  equipment   and 
associated  software. 

(3)  Configuration  and  interface  management  of  tactical 
digital  equipment  and  software." 

On  3  November  1971  TADSO  published  its  first  Tactical 
Digital  Standard  (TADSTAND  1)  [Ref.  2]  which  established  the 
AN/OYK-7  processor  as  the  standard  computer  for  shipboard 
applications  and  the  CMS-2  high-level  language  as  the 
standard  high-level  language  to  be  employed  in  the 
production  of  operational  programs  for  tactical  data 
systems.  TADSTAND  1  also  provided  that  a  request  for 
deviation  from  these  standards  could  be  initiated  to  TADSO 
if  it  was  thought  to  be  in  the  best  interests  of  the  Navy  to 
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use  either  another  Navy  computer  or  a  computer  not  presently 
in  the  Navy  inventory. 

In  response  to  TADSIAND  1  some  requests  to  deviate  from 
the  OYK-7  standard  were  received.  The  most  significant 
justification  given  was  that  the  OYK-7  was  too  large  and 
expensive  ($720,000  average  cost)  for  the  intended 
application.  (See  App.  A  for  a  description  of  the  OYK-7 
computer.)  Out  of  this  identified  need  for  a  smaller 
computer  grew  the  AN/OYK-20  (V)  Data  Processing  System  (DPS) , 
the  Navy  standard  minicomputer. 

It  is  the  purpose  of  this  chapter  to  establish  the 
meaning  and  implications  of  the  terms  "minicomputer"  and 
"standard",  to  identify  the  capabilities  needed  within  the 
Navy  in  a  standard  minicomputer  system,  and  to  establish 
whether  or  not  these  capabilities  could  be  met  by  a  small 
computer  existing  in  the  Navy  inventory  in  1972. 


A.   DEFINITION  OF  A  MINICOMPUTER 

Commercially  available  computers  in  1972  formed  almost  a 
continuous  spectrum  in  size,  power  and  capabilities. 
Naturally,  it  is  is  difficult  to  separate  the  minicomputer 
from  larger  or  smaller  types. 

The  possibility  of  a  small  computer  with  useful 
capabilities  and  memory  capacity  grew  with  the  development 
of  hybrid  and  integrated  circuits  in  the  mid-1960' s.  In 
1970  medium-  and  large-scale  integration  was  introduced, 
allowing  even  more  capability  to  be  designed  into  a  small 
package.  At  the  same  time  these  advancements  were  reducing 
hardware  costs  at  the  rate  of  an  order  of  magnitude  per 
decade.  The  advent  of  mini-peripherals  specifically 
designed  for  use  with  minicomputers  was  the  final  addition 
to  complete,  low-cost  mini-systems.  At  that  time,  as  was 
still  true  in  1976,  software  was  the  predominant  cost  of 
such  systems. 
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C.  Weitzman  [Ref.  11]  defined  the  minicomputer  as  an  8- 
to  18-  bit  word  size  machine  with  memory  size  from  1K  to  32K 
words.  Costs  range  from  $4,000  to  $100,000.  The 
minicomputer  is  generally  catagorized  as  having  limited 
accuracy,  low  speed  for  double-precision  arithmetic 
operations  and  no  floating-point  hardware.  By  1972, 
however,  many  minicomputers  had  multiple  Input/Output  (I/O) 
access  features  and  microprogrammable  central  processors 
allowing  extensive  instruction  repertoires  with  firmware 
implementation  of  floating-point  and  special  mathmatical 
functions.  A  more  detailed  discussion  of  the  minicomputer 
technology  of  the  early  1970's  may  be  found  in  Chapter  IV, 
section  B. 


B.   DEFINITION  AND  IMPLICATIONS  OF  A  "STANDARD" 

A  "standard"  could  be  defined  as  a  specific  entity  which 
will  be  used  in  every  application  where  an  entity  of  that 
general  description  is  required. 

The  contents  of  the  several  TADSTANDS  published  by  TADSO 
imply  the  following  Navy  policy  concerning  a  "standard": 

The  entity  identified  as  a  "standard"  will  be  used  in 
all  developing  and  future  tactical  digital  system 
applications  except  where  deviation  is  specifically 
provided  for,  requested  and  approved. 

References  3  through  9  are  the  standards  promulgated  by 
TADSO  as  of  May  1976.  The  impact  of  such  standards  in  user 
system  design  will  be  discussed  in  Chapt.  IV.  The 
implications  of  establishing  standards  are  summarized  in  the 
following  paragraphs. 

Standardization  allows  realization  of  the  economies  of 
large  scale  production.  For  example,  as  of  May  1976,  824 
AN/0YK-20  Data  Processing  Systems  had  been  ordered   and  637 
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units  delivered.  At  that  time  there  were  107  programs  using 
the  system. [Fig. 2 ]  At  the  outset  of  the  UYK-20  acquisition 
the  estimated  production  run  was  in  excess  of  4500  units. 
This  volume  is  over  an  order  of  magnitude  greater  than  any 
one  program  would  require  in  an  independent  processor 
acquisition.  Clearly,  the  economies  of  scale  would  be 
realized  with  such  a  program.  Although  it  is  impossible  to 
quantify  the  actual  savings  realized  by  using  UYK-20  in  any 
particular  project,  the  economies  of  scale  are  demonstrated 
in  the  volume  order  prices  for  an  AN/UYK-20  (V)  DPS  basic 
configuration  in  fiscal  year  1974: 

Quantity  -  50  at  $25,966  each 
Quantity  -  100  at  $24,735  each 
Quantity  -  150  at  $24,324  each 

It  is  also  interesting  to  note  that  the  Fiscal  Year  (FY) 
1976  order  price  for  a  similar  configuration  is  about 
$25,000  each,  approximately  the  same  as  the  FY  74  price 
despite  inflation. 

Standardization  realizes  cost  savings  in  material 
support.  One  project  manager  estimated  that  the  cost  of 
introducing  one  new  part  into  the  Navy  Supply  System  at  SPCC 
is  about  $1500.  It  has  also  been  estimated  that  the  Navy 
realizes  $20,000  to  $40,000  per  year  in  Integrated  Logistic 
Support  (ILS)  cost  savings  through  a  standardized  system 
like  UYK-20. 

Standardization  avoids  duplication  of  support  software 
costs.  A  project  manager  estimated  a  savings  of  $2,000,000 
to  $4,000,000  per  year  in  software  maintainance  costs  for  a 
project  using  a  standard  computer. 

Standardization  reduces  the  scope  of  required 
maintenance  training.  The  Chief  of  Naval  Technical  Training 
emphasized  this  fact  in  a  letter  to  the  Director  of  TADSO, 
pointing  out  that  it  was  becoming  increasingly  difficult  to 
fill   technical  training   billets,  and  that  standardization 
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programs  like  AN/UYK-7  help  alleviate  this  problem .[ Ref. 10 ] 
It  is  estimated  that  about  $409,000  per  year  savings  in 
technical  training  costs  is  realized  through  the  existence 
of  OYK-20. 

Standardization  can  reduce  the  amount  of  training 
required  for  operator  personnel.  Lack  of  standardization 
may  mean  that  as  an  operator  is  transferred  from  one  command 
to  another  he  must  be  sent  back  to  school  to  learn  new 
equipment.  Such  an  occurrence  has  a  direct  impact  on  fleet 
readiness  and  personnel  training  costs.  As  an  example,  the 
REWSON  program  faces  this  problem  because  some  of  its  shore 
installations  utilize  DSC  PDP-11  computers  while  the 
associated  shipboard  installations  employ  AN/U5TK-20  Data 
Processing  Systems. 

Standardization  saves  the  repetitive  acquisition  costs 
of  procurements  of  unique  systems.  These  costs  include  the 
recurring  costs  for  ILS,  software  maintenance,  etc.  and  also 
the  one-time  development  costs.  As  an  example,  the  OYK-20 
acquisition  required  $1.3  million  in  Research  &  Development 
funding  for  militarization  of  commercial  hardware,  support 
software,  documentation,  etc. 

Despite  these  strong  arguments  in  favor  of 
standardization,  there  is  much  resistance  to  any 
standardization  program.  Mr.  Howard  Gantzler,  Deputy 
Assistant  Secretary  of  Defense  (Installations  5  Logistics) , 
recognized  that  attitude  when  he  stated  at  a  seminar  given 
at  the  Naval  Postgraduate  School  in  January  1976, 

"Everybody  is  in  favor   of   it  [standardization],   but 
nobody  wants  to  adopt  someone  else's  standards." 

Rear  Admiral  E.  B.  Fowler,  Vice  Commander  of  the  Naval 
Electronics  Systems  Command  identified  another  drawback  of 
standardization  in  an  address  to  the  Naval  Postgraduate 
School  chapter  of  the  IEEE  in  April  1976. 
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"You  have  to  standardize.  You  can't  afford  not  to  do 
so.  But  you  must  also  get  a  firm  grip  on  the  half-life 
of  the  thing  you  are  standardizing...  AN/UYK-20  was 
thought  at  first  to  be  a  five  year  investment.  We  are 
currently  reprocurring,  and  it  looks  like  ten  to 
fifteen  years.  The  CP-642B's  [CP-642B  computer  (ONIVAC 
1212).  See  Chapt.  II,  sect.  D. ]  have  been  around  for 
sixteen  to  seventeen  years,  and  we  put  them  on  the 
Nimitz,  the  newest  capital  ship.  This  is  a  systems 
engineering  problem." 

In  that  statement  admiral  Fowler  suggests  that  once  a 
standard  is  established,  it  may  be  used  for  many  more  years 
than  anticipated  unless  a  firm  policy  for  replacement  is 
adopted  at  the  outset.  Understandably,  the  majority  of 
opposition  to  standardization  was  found  by  this  author  in 
the  technical  community,  which  must  design  systems  using 
standardized  components  not  specifically  tailored  to  the 
tasks  required. 


C.   THE  RANGE  OF  CAPABILITIES  NEEDED 

In  January  1972,  a  Design  Review  Group  (DRG)  was 
convened  by  TADSO  to  translate  the  requirements  of  the  Navy 
for  a  minicomputer  system  into  a  specification  which  could 
be  used  as  the  basis  for  competitive  bidding.  It  is 
significant  to  note  that  the  intent  was  not  to  fill  the 
entire  range  of  size  and  power  below  the  UYK-7,  but  only  to 
fill  the  identified  current  and  future  needs.  Thus,  from 
the  outset  the  success  of  UYK-20  depended  on  accurate 
prediction  of  those  needs  by  the  DRG.  The  composition  of 
the  DRG  was  most  important,  and  it  is  interesting  to  note 
the  commands  represented:  Naval  Ordnance  Systems  Command 
(ORD-532)  ,  Naval  Ships  Systems  Command  (SHIPS-0352'4)  ,  Naval 
Air   Systems   Command   (&IR-5333F) ,   Naval  Ships  Engineering 
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Center  (SEC-6178D  and  SEC-6172),  H.  Q.  Marine  Corps  (Code 
AAM-4)  ,  Fleet  Combat  Direction  System  Support  Activities 
Pacific  and  Atlantic,  and  Naval  Weapons  Laboratory  Dahlgren. 
The  Naval  Ordnance  Systems  Command  and  the  Naval  Ships 
Systems  Command  have  since  been  combined  into  one  command 
designated  the  Naval  Sea  Systems  Command  (NAVSEA) .  Thus  all 
the  commands  responsible  for  systems  development  were  well 
represented. 

In  order  to  save  time  and  development  costs,  TADSO  had 
conceived  an  "off-the-shelf"  procurement.  That  was  an 
important  decision,  which  implied  that  the  intent  was  to 
procure  a  market-tested  computer  system  which  would  only 
need  to  be  militarized. 

Since  the  computer  was  to  be  general  purpose  and  serve  a 
wide  range  of  diverse  applications,  a  modular  building  block 
approach  was  conceived.  A  basic  configuration  was  to  be 
specified  and  plug-in  modules  provided  so  that  the  user 
could  increase  the  size  and  power  of  the  processor  up  to  his 
individual  needs.  Add-on  modules  were  to  be  individually 
priced  so  that  the  user  only  paid  for  the  capability  he 
needed.  The  following  paragraphs  summarize  the  range  of 
capabilities  which  TADSO  and  the  DRG  foresaw  would  be  needed 
to  meet  Navy  systems  reguirements  of  1972  and  about  five 
years  into  the  future. 

1 .   Packaging 

The  computer  would  be  required  to  meet  military 
specification  MIL-E-16400  for  shipboard,  groundbased,  and 
submarine  electronic  systems.  This  decision  precluded 
airborne  applications  of  the  computer,  which  would  have 
required  the  more  stringent  and  expensive  MIL-E-5400 
specification,  but  would  have  expanded  the  applications  and 
thus  the  volume  of  production.  The  reason  behind  that 
decision  was  the  intention  to  produce  an  interim  standard 
shipboard  computer  to  be  eventually  replaced  by  the 
All-Applications  Digital  Computer   (AADC)   which   was   then 
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under  development  by  the  Naval  Air  Systems  Command  (NAVAIR)  . 
The  AADC  never  materialized,  and  as  of  1975  the  AADC  project 
had  been  redirected  to  produce  an  Interim  Standard  Airborne 
Digital  Computer  (ISADC) .  Out  of  the  ISADC  project  came  the 
AN/AYK-14  computer  in  1976. 

The  computer  was  to  be  packaged  in  one  enclosure  of 
maximum  dimensions  26  inches  high,  24  inches  deep,  and  width 
suitable  for  mounting  in  a  standard  19-inch  rack.  Maximum 
power  consumption  was  to  be  one  kilowatt. 

To  achieve  the  desired  building  block  capability, 
the  following  units  were  to  be  strictly  plug-in  with  no 
other  hardware  changes  necessary  to  install:  memory  modules 
of  8K-words  per  module,  I/O  channels  in  groups  of  two  if 
serial  and  in  groups  of  four  if  parallel,  real-time  clock, 
general  registers,  and  microprogrammable  control  memory. 

2«   Reliability  and  Maintainability 

In  accordance  with  MIL-E-16400,  modular  construction 
was  specified.  All  assemblies  with  a  cost  of  $200  or  less 
would  be  throw-away  components.  Only  those  assemblies  where 
it  was  determined  that  repair  would  be  more  cost-effective 
than  throw-away/replacement  would  be  designated  as 
repairable  modules.  It  was  further  specified  that  repairs 
would  be  performed  by  the  contractor,  a  factor  which  had  a 
later  impact  on  the  repairable  turn-around  time. 

The  maximum  configuration  of  the  computer  was  to 
have  a  Mean  Time  Between  Failures  (MT3F)  of  2000  hours,  a 
Mean  Time  to  Repair  (MTTR)  of  15  minutes  and  a  Maximum  Time 
to  Repair  of  120  minutes.  The  MTBF  specified  was  a  figure 
which  had  been  used  on  previous  military  computer 
specifications.  As  far  as  the  author  of  this  thesis  could 
determine,  the  basis  for  citing  the  2000  hour  figure  was 
historical  rather  than  the  result  of  calculation. 

The  computer  was  to  be  logically  and  electrically 
designed  to  facilitate  the  isolation  of  malfunctioning 
modules   through   diagnostic   programming.    The   diagnostic 
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program  was  to  isolate  95%  of  recurring  (non-intermittent) 
active  logic  element  failures  to  not  more  than  three  printed 
circuit  card  modules. 

3 .   Architecture 

The  computer  was  to  employ  third  generation 
technology  with  the  use  of  medium-scale  integration. 

Perhaps  the  most  significant  architectural 
requirement  was  that  the  processor  was  to  be 
microprogram mable.  The  rationale  for  requiring  this 
capability  was  the  possibility  of  a  more  powerful 
macro-instruction  set  and  the  flexibility  to  modify  or  add 
to  the  macro-instruction  set  by  simply  modifying  the 
contents  of  control  memory.  An  additional  requirement  was 
therefore  for  at  least  500  words  (16-bit)  of  user  growth 
capacity  in  the  control  memory. 

Other  required  architecture  attributes  were:  word 
length  at  least  16-bits  including  sign  but  not  including 
parity,  random  access  non-volatile  memory  with  a  separate 
high  speed  memory  desireable  but  not  required,  main  memory 
read-restore  cycle  time  less  than  1.2  microseconds, 
asynchronous  timing  with  at  least  one  level  of  memory  fetch 
instruction  overlap  to  create  an  effective  memory  cycle  time 
of  less  than  one  microsecond,  minimum  storage  capacity  of 
8K-words  expandable  to  at  least  65K-words  (directly 
addressable)  in  8K-word  increments,  a  minimum  of  four 
general  registers  expandable  to  sixteen. 

It  was  significant  that  no  requirement  was  made  for 
a  capability  to  expand  memory  capacity  beyond  65K-words. 
Also  significant  was  the  absence  of  requirements  for  parity 
checking,  memory  write  protection  or  executive  mode  with 
privileged  instructions. 

The  question  of  parity  checking  was  a  much  discussed 
attribute.  Those  in  favor  cited  the  need  to  identify 
hardware  errors,  particularly  in  memory  accesses,  when 
attempting  to  debug  software.   In  addition,   arguments   were 
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made  in  favor  of  identifying  errors  when  executing 
operational  programs  to  prevent  miscalculations  of  target 
information,  misrouting  of  data  (particularly  in  message 
handling  systems) ,  mishandling  of  classified  information/ 
etc.  The  arguments  against  parity  pointed  to  the 
significant  cost  in  real  estate  (extra  bits  and  about  10% 
more  logic)  and  extra  memory  bits  per  word.  It  was  argued 
that  parity  error  detection  had  little  value  in  modern 
digital  equipment  since  this  attribute  was  designed  to 
detect  single  bit  failures  rather  than  catastrophic  logic 
failures  affecting  whole  blocks  of  addresses;  the  latter 
type  of  failure  characterized  the  type  of  failure  most  often 
encountered  in  modern  equipment.  Operationally  it  was 
thought  undesireable  to  interrupt  processing  of  critical 
target   data  to  process  parity  errors  in  a  combat  situation. 

In  the  end  the  cost  considerations  prevailed. 
Although  the  question  of  memory  protection  was  not  discussed 
to  the  same  extent  as  memory  parity  checking,  similar  cost 
and  real  estate  savings  could  be  realized  by  not  including  a 
hardware  memory  protection  feature  in  the  design. 

The  macro-instruction  set  specified  provided  for 
single  and  double  word  addition,  subtraction, 
multiplication,  division,  logical  operations,  shifts,  jumps, 
and  a  programmable  stop.  In  a  non-dual-state  machine  the 
programmable  stop  would  be  non-privileged,  making  it  a 
controversial  attribute.  Only  load,  add,  subtract  and  store 
byte  operations  were  specified,  and  no  bit  manipulation 
instructions  were  required.  It  is  significant  that  all 
operations  specified  were  arithmetic  (recognizing  the  most 
significant  bit  of  a  word  as  the  sign)  so  that  no  capability 
for  full  16-bit  data  manipulation  was  required.  Instruction 
execution  times  were  specified  as  follows: 

Instruction     Register -to- Register   Memory- to- Register 
Add, Subtract    1.2  microseconds      2.2  microseconds 
Load, Store     N/A  2.2  microseconds 
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Multiply  9  microseconds  11  microseconds 
Divide  20  microseconds  22  microseconds 
Shift (16-bit)   7  microseconds        N/A 

The  computer  was  to  be  capable  of  executing  not  less  than 
500,000  instructions  per  second  for  the  following 
distribution  of  memory-to-register  instructions: 

Instruction  Tyjae  Percent  of  Mix 

Add,  or  equivalent  34 

Logical  or  masking  34 

Branch (Jump)  13 

Multiply  5 

Divide  1 

Miscellaneous  _J 

100 

The  choice  between  one* s-complemsnt  or 
two's-complement  arithmetic  was  left  to  the  contractor, 
despite  the  fact  that  most  previous  Navy  computers  were 
one's-complement  machines.  That  decision  would  impact  on 
future  software  compatibility  and  system  integration. 

The  DRG  specified  at  least  single-level  indirect 
addressing,  indexing,  and  relative  addressing  to  a  fixed 
base  which  could  be  program  modified. 

A  hardware  (or  firmware)  capability  to  load  programs 
(bootstrap)  was  to  be  provided.  The  intent  was  that  the 
bootstrap  would  be  a  plug-in  option  wherein  the  user  could 
obtain  bootstrap  capability  for  the  particular  peripheral 
and  channel  desired. 

**  •   Input/Output 

It  was  intended  that  the  I/O  structure  be  such  that 
the  I/O  channels  access  memory  through  a  second  memory  port, 
eliminating  interference  with  processor  operations.  This 
requirement  meant  that  an  arithmetic  unit,   data   registers, 
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etc.  were  required  for  each  channel  to  perform  buffer 
control  functions,  address  calculations,  interrupt  control, 
etc.  In  order  to  save  on  real  estate,  the  channels  (a  total 
of  sixteen)  were  to  be  grouped  in  increments  of  not  more 
than  four  channels  for  parallel  mode,  or  two  channels  for 
serial  mode.  Only  one  aider  and  set  of  data  registers  plus 
control  circuitry  would  be  required  per  four  channel  group. 
This  requirement,  while  saving  circuitry  and  cost  placed 
several  significant  restrictions  on  possible  I/O 
configurations: 

*  For  parallel  mode  data  transfer,  each  four  channel 
group  was  constrained  to  one  type  of  interface. 

*  Serial  and  parallel  channels  could  not  be  mixed 
within  a  group. 

*  Double  word  (32-bit)  transfers,  such  as  necessary  for 
interfacing  with  UYK-7,  would  require  one  channel 
from  each  of  two  adjacent  groups,  thus  forcing  eight 
channels  to  be  of  the  same  type  of  interface.  (This 
requirement  stems  from  the  need  for  separate 
processing  circuitry  for  the  upper  and  lower  16-bits 
of  32-bit  parallel  transfers.) 

Direct  Memory  Access  (DMA)  was  desired  but  not 
required.  Thus,  a  provision  for  direct  memory  access  by  a 
high  speed  mass  storage  device  (such  as  a  disk)  could 
somewhat  compensate  for  the  lack  of  provision  for  expansion 
of  main  memory  beyond  65K-words. 

Various  types  of  interfaces  were  to  be  provided  as 
options: 

*  Parallel  (MIL-STD-1397) 

■  NTDS  Past  (-3  volts) 

•  NTDS  Slow  (-15  volts) 

■  ANEW  (+3.5  volts) 
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*  Serial 

■  RS-232C   synchronous   and  asynchronous   normal 
speeds 

■  MIL-STD-188C  synchronous  and  asynchronous  normal 
speeds 

■  MIL-STD-1397  (NTDS)  32-bit  serial 

■  MIL-STD-188C  high  speed  (up  to  one  million   bits 
per  second) 

All  parallel  types  were  to  provide  full  duplex 
operation  in  a  normal  data  transfer  (16-  or  32-bit)  mode,  an 
intercomputer  mode,  or  an  externally  specified  address  (ESA) 
mode.  Asynchronous  serial  channels  were  to  provide 
full-duplex  operation  at  bit  rates  of  75,  150,  300,  600,  and 
1200  bits  per  second  (baud)  with  2400,  4800  and  9600  baud 
desireable. 

5.  Interrupts 

A  priority  structure  of  interrupts  was  specified 
with  the  following  types  of  interrupts  required  (in  order  of 
priority,  highest  to  lowest) :  power  failure  protection, 
instruction  fault,  real-time  clock  overflow,  internal  clock 
interrupt,  intercomputer  time-out,  external  device  interrupt 
and  I/O  interrupts. 

Despite  the  usefulness  of  nesting  interrupts,  the 
specification  required  only  that  interrupts  occuring 
simultaneously  be  nested.  Furthermore,  the  specification 
required  that  all  interrupts  of  lower  priority  be  disabled 
while  processing  an  interrupt. 

6.  Control/Ma in tenaace  Panel 

The  specification  required  that  a 
control/maintenance  panel  be  provided  that  could  be,  but  was 
not  required  to  be  separate  from  the  computer.  Noraal  panel 
displays,  indicators  and  controls  were  to  be  provided  (these 
were   specified   in  detail) .   Significantly,  the  panel  could 
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be  configured  to  display  only  one  register  at  a  time,  or 
more,  as  the  manufacturer  wished. 

7 .   Software 

It   is  significant  that  the  question  of  software  was 

not  addressed  in  the  specification  generated  by  the  DRG.  In 

the  Request-for-Proposals  (RFP)  only  an  assembler  was 
required. 

Appendix   B  summarizes  the   specifications  for  the 

standard  minicomputer  system  as  determined  by  TADSO  and  the 
DRG. 


D.   CAPABILITIES  OF  EXISTING  NAVY  COMPUTERS  TO  MEET  THE 
SPECIFICATIONS 

It  is  valid  to  investigate  whether  the  perceived  present 
and  future  needs  of  the  Navy  for  a  minicomputer,  as  defined 
by  the  DRG,  could  be  met  by  an  existing  general  purpose 
small  computer  in  the  Wavy  inventory.  If  so,  this  computer 
could  be  designated  a  standard  just  as  the  AN/UYK-7  had  been 
a  year  before. 

The  sections  below  discuss  the  pertinent  features  of 
some  of  those  Navy  computers  which  would  have  been  most 
likely  to  fill  the  need  for  a  standard  minicomputer. 
Appendices  C  through  F  summarize  the  characteristics  of 
those  computers. 

Comparing  the  standard  minicomputer  specification  with 
the  existing  computers  reveals  that  none  met  the 
specification  completely,  although  two  were  good  candidates 
with  certain  exceptions.  The  AN/UYK-15(V)  lacked 
microprogramming  and  relative  addressing,  but  was  otherwise 
acceptable.  It  had  additional  features  such  as  memory  parity 
checking,  memory  write  protection  and  multi-ported  memory 
banks  to  further  recommend  it.  The  AN/UYK- 1 2  (V)  also  lacked 
microprogramming   and  did  not  meet  all  required  instruction 
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execution  speeds  or  memory  capacity,  but   had  an   extensive 
support  software  package  to  recommend  it. 

The  existence  of  UYK-12  and  UYK-15  brings  the  decision 
to  specify  a  microprogrammed  processor  under  close  scrutiny. 
As  discussed  in  the  previous  section,  the  advantages  of 
microprogrammability  are  an  expanded  macro-instruction  set, 
ability  to  implement  high  speed  floating-point,  mathematical 
and  trigonometric  functions  as  needed,  and  flexibility  to 
add  high-speed  user  macros  to  facilitate  real-time 
processing.  The  disadvantages  were  best  summarized  in 
enclosure  (1)  of  a  letter  to  TADSO  from  the  Naval  Air 
Systems  Command  (AIR-5333) , 

"The  latter  deficiency  [the  requirement  for 
micro-programmability ],  while  being  technically 
feasible,  leads  to  unusual  hardware  and  software 
configuration  management  problems.  NAVAIR  believes 
that  a  requirement  for  micro-programmability  has  not 
been  demonstrated  and  will  serve  only  to  eliminate 
qualified  vendors. "[ Ref.  13] 

NAVAIR* s  comments  about  configuration  management  refer 
to  the  potential  user  capability  to  modify  the 
macro-instruction  set.  It  must  be  pointed  out  that 
configuration  control  can  be  maintained  by  requiring  that 
all  modifications  to  the  macro-instruction  set  be  upward 
compatible  with  the  basic  set. 

The  foregoing  comments  not-withstanding, 
microprogrammability  remained  a  requirement,  and  none  of  the 
existing  Navy  computers  could  meet  the  specification.  It  is 
also  interesting  to  note  that  a  majority  of  the  computers  in 
the  Navy  inventory  were  manufactured  by  the  UNIVAC  Defense 
Systems  Division  of  Sperry  Rand  Corporation  (UNIVAC) .  The 
Rolm  Corporation  manufactured  AN/UYK- 12 (V)  is  an  exception, 
and  there  were  others.  Comparison  of  the  standard 
minicomputer   specification   with   the   UNIVAC   manufactured 
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computers  reveals  that  the  DRG  was  probably  influenced  by 
the  ONIVAC  design  philosophy  in  producing  their 
specification.  For  instance,  the  UYK-12  I/O  structure, 
which  was  not  in  accordance  with  the  specification,  was 
simply  another  method  of  accomplishing  the  same  end.  It  is 
the  opinion  of  this  author  that  the  use  in  the  RFP  of  the 
detailed  technical  specification  produced  by  the  DRG  rather 
than  a  performance  specification,  probably  excluded  some 
candidate  minicomputers  from  the  competition. 

1-   CP-642B 

This  computer,  a  militarized  version  of  the  ONIVAC 
1212,  was  an  upward  compatible  follow-on  to  the 
USQ-20/CP-642/CP-6  42A  family.  Designed  specifically  for  use 
in  the  Navy  Tactical  Data  System  (NTDS) ,  its  architecture 
optimized  processing  of  large  quantities  of  complex  data 
where  heavy  I/O  comunication  was  required.  With  reference 
to  App.  C  it  can  be  seen  that  although  CP-642B  was  a 
minicomputer  in  capabilities,  it  was  a  physically  larger 
unit  than  desired.  Its  size  and  slow  speed  are  a  result  of 
its  second  generation  architecture.  Lack  of  serial  I/O 
capability,  lack  of  interrupts  and  limited  memory  were  other 
factors  which  made  this  computer  unacceptable.  Appendix  C 
profiles  the  CP-64  2B. 

2 .   AN/DYK-15  (  V) 

The  shortcomings  of  this  computer,  a  militarized 
UNIVAC  1616,  have  been  previously  discussed.  Additional 
desireable  features  incorporated  in  the  AN/UYK-15(V)  include 
optional  additional  general  registers  up  to  64,  memory 
parity  checking  and  a  priority  structured,  multi-ported 
memory.  This  latter  feature  incorporates  a  priority 
multiplexer  which  provides  four  access  ports  for  each 
16K-word  memory  bank.  Combined  with  separate  IOC's  for  each 
group  of  four  I/O  channels,  this  feature  allows  simultaneous 
access   to   different   memory   banks   by  the  CPU  and  various 
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IOC's,  thus  improving  throughput.   Appendix  D  profiles  the 
AN/UYK-15(V) . 

3.   CP-3.SC 

Commercially  designated  the  UNIVAC  1289,  this 
computer  was  designed  for  navigation  system  applications. 
Although  of  second  generation  technology,  it  featured 
reasonable  speed.  It  failed  in  a  number  of  ways  to  meet  the 
standard  minicomputer  specification,  but  it  had  some 
capabilities  not  required,  but  desireable:  dual  states 
(program  and  executive) ,  programmable  memory  read/write 
protection,  memory  parity  checking,  and  floating-point 
hardware.   Appendix  E  profiles  the  CP-890. 

a .  AN/aYK-12  m 

That  computer  was  designed  from  the  ground  up  as  a 
militarized  Data  General  NOVA  with  a  military  application 
I/O  structure  added.  Designated  the  Rolm  1601,  it  was 
completely  upward  compatible  with  the  NOVA  and  could  thus 
run  all  software  developed  for  that  popular  minicomputer. 

The  I/O  structure  was  basically  a  singla  I/O  bus 
with  the  facility  to  address  61  different  devices.  Each 
device  could  independently  interrupt  the  processor  according 
to  a  predetermined  priority.  The  computer  could  be 
configured  with  up  to  16  I/O  interfaces  and  15  backpanel 
connectors. 

An  extensive  package  of  well-tested  and 
well-documented  support  software  was  available.  Included 
were  cross-assemblers  and  cross-compilers  so  that  programs 
for  the  UYK-15  could  be  assembled  or  compiled  on  a  larger 
machine.  That  feature  recognized  the  constraints  on  using  a 
minicomputer  for  program  development. 

In  this  chapter  the  meaning  and  implications  of  a 
standard  minicomputer  have  been  established.  The  Navy 
requirements  for  a  minicomputer  system  in  1972  were 
discussed,   and   it   was   concluded   that   no  existing  small 
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computer  in  the  Navy  inventory  could  meet  those 
requirements.  In  Chapt.  Ill  the  history  of  the  standard 
minicomputer  acquisition  project  will  be  discussed. 
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III.   DEVELOPMENT  AND  PRODUCTION  HISTORY 

The  events  leading  to  the  publication  of  a  specification 
for  a  standard  minicomputer  have  been  detailed  in  the 
previous  chapter.  This  chapter  will  relate  the  history  of 
the  AN/UYK-20(V)  acquisition  from  specification  to  mid-year 
1976.  Much  of  the  information  on  events  leading  to  the 
contract  award  in  May  1973  was  derived  from  a  research  paper 
by  Captain  J.  S.  Sansone  [Ref.  14],  who  was  the  Project  and 
Contracting  officer  for  the  standard  minicomputer 
procurement. 

In  June  1972  the  preliminary  specification  for  the 
standard  minicomputer  was  distributed  for  final  review.  By 
that  time  TADSO  was  well  established  and  had  issued  six 
TADSTANDS  on  a  variety  of  subjects.  [Refs.  2-8]  The 
acquisition  strategy  called  for  militarization  of  a 
commercial  system  requiring  a  minimum  of  system  development 
to  meet  the  DRG  specification.  It  was  estimated  that  about 
$1.8  million  in  Research,  Development,  Test  and  Evaluation 
Navy  (RDT&EN)  appropriated  funds  would  be  necessary  to  cover 
costs  of  design  and  devalopment,  militarization,  Government 
Furnished  Equipment  (GFE) ,  environmental  and  reliability 
testing,  TEMPEST  testing,  Integrated  Logistics  Support 
plans,  development  of  technical  manuals,  other  data 
requirements,  and  support  software  development. 

In  late  August  1972  CNM  advised  CNO«s  Director  of 
Research,  Development,  Test  and  Evaluation  (OP-098)  of  the 
existance  of  the  standard  minicomputer  specification,  and 
the  need  for  prompt  approval  to  preclude  further 
proliferation  of  commercial  minicomputers  in  the  Navy 
inventory.  OP-098  was  also  informed  that  the  necessary  $1.8 
million  in  RDT&EN  funds  could  be  obtained  by  reprogramming 
Fiscal   Year   1973  funds  from  sub-allocations  to  the  various 
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projects  who  would  use  the  standard  minicomputer.  Since  the 
amount  of  funds  to  be  reprogrammed  did  not  exceed  $2 
million,  prior  approval  from  the  Secretary  of  Defense 
(SECDEF)  and  the  Armed  Services  and  Appropriations 
Committees  of  Congress  was  not  required.  Reprogramming 
could  be  carried  out  within  the  Department  of  the  Navy  with 
the  approval  of  the  budget  activity  sponsor  (OP-098) .  There 
was  sufficient  justification  for  this  plan  since  the  user*s 
funds  would  have  been  used  for  a  computer  procurement 
anyway.  However,  the  plan  raised  potential  user  project 
manager  objections.  First,  control  over  the  design  and 
development  of  the  minicomputer  would  be  taken  out  of  the 
hands  of  the  project  managers  and  vested  in  an  independent 
office.  Second,  great  risks  were  involved  in  the  delivery 
schedule.  Third,  ELEX-560  could  not  have  the  specific  needs 
of  all  the  user  projects  at  heart  when  making  tradeoff 
decisions  regarding  cost,  schedule  and  performance. 

By  mid-September  1972  the  approval  of  CNO  was  assured. 
CNM  tasked  the  Commander,  Naval  Electronic  Systems  Command 
(CCMNAVELEX)  to  handle  the  procurement.  In  response, 
C0MNA7ELEX  created  a  division  within  his  Material 
Acquisition  Directorate  (ELEX-05)  to  carry  out  this  task. 
The  division  was  designated  the  Standard  Tactical  Digital 
Equipment  Division  (ELEX-560).  [Fig.  3]  At  this  time  the 
procurement  plan  specified  a  formally  advertised  two-step 
procurement  based  on  the  DRG  specification  and  resulting  in 
a  firm-fixed-price  contract. 

In  October  1972,  in  response  to  TADSTAND  1,  TADSO 
received  a  request  from  the  Mk68  Gunfire  Control  System 
(GFCS)  project  to  deviate  from  the  OYK-7  standard  in  favor 
of  a  commercial  minicomputer.  The  request  was  subsequently 
denied,  and  the  requirements  of  the  Mk68  GFCS  project  became 
the  first  firm  requirements  for  standard  minicomputer 
systems.  The  constraints  of  the  Mk68  GFCS  project  schedule 
were  thus  imposed  on  the  standard  minicomputer  procurement. 

The   new   schedule  constraints  forced  abandonment  of  the 
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formal  two-step  procurement  in  favor  of  an  accelerated  plan. 
The  plan  called  for  a  negotiated  procurement  under 
paragraphs  2304  (a)  (2)  and  (10)  of  Title  10  of  the  United 
States  Code.  Those  regulations  allowed  a  negotiated 
procurement  in  lieu  of  a  formally-advertised,  sealed-bid 
competition  in  cases  where  the  exigency  would  not  permit  the 
delay  incident  to  formal  advertising  and  when  it  was 
impractical  to  obtain  competition.  Significant  milestones 
adopted  were: 

*  Issuance  of  the  Request  for  Proposals  (RFP)  by  1 
December  1972 

*  Award  of  the  contract  by  22  February  1973 

*  Delivery  of  the  first  Functional  Demonstration  Models 
(FDM  -  non-militarized  prototype)  30  days  after  award 
of  contract 

*  Commencement  of  testing  by  22  September  1973 

*  Delivery  of  the  first  Advanced  Production  Engineering 
Models  (APE  -  militarized  prototype)  nine  months 
after  award  of  contract 

*  Delivery  of  the  first  production  units  by  May  1974 

Technical  evaluation  (TECHEVAL)  would  be  completed  in  the 
contractors  plant  and  operational  evaluation  (OPEVAL)  would 
be  completed  concurrently  with  the  OPEVAL  of  the  first  user 
system.  A  firm-fixed-price  contract  was  anticipated.  The 
accelerated  plan  precluded  detailed  analysis  of  proposals  to 
determine  which  contractor  offered  the  best  performance  per 
price.  It  was  planned  to  simply  select  the  lowest  bidder 
among  those  found  responsive  to  the  DRG  specification. 
Thus,  little  improvement  on  the  DRG  design  was  possible 
through  the  acquisition  process. 

On   15  November  1972,  CNM  declared  the  DRG  specification 
as   the   Navy  standard   minicomputer    specification   and 
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constrained  all  projects  planning  or  procuring  minicomputers 
to  use  the  standard  as  Government  Furnished  Equipment  unless 
approval  was  obtained  from  TADSO  to  deviate.  [Ref.  15]  Three 
projects  in  addition  to  MJc68  GFCS  were  specifically  directed 
to  switch  to  the  standard  minicomputer  for  their  production 
phase:  the  SPS-48  Radar  Improvement  Program,  which  had  gone 
through  development  with  the  AN/UYK-15  (V)  computer;  the 
Carrier  Tactical  Support  Center  project  (CVTSC) ,  which  had 
gone  through  development  with  the  IBM  SP-1  computer,  and  the 
Satellite  Communications  program  (SATCOM) ,  which  had  gone 
through  development  with  the  Rolm  Corporation  1602  computer. 
This  directive  was  probably  premature  since  all  projects 
were  then  forced  to  include  in  their  production  plans  a 
component  that  was  only  a  piece  of  paper  with  no  proposals 
in  hand  to  guarantee  the  feasibility  of  meeting  the  proposed 
schedule  milestones. 

The  establishment  of  the  specification  as  a  standard 
resulted  in  identification  of  more  projects  requiring  a 
minicomputer.  As  of  mid-November  1972  estimated 
requirements  for  some  314  production  units  (through  Fiscal 
Year  1974)  had  been  identified.  Since  this  figure  was 
expected  to  change,  and  delivery  dates  were  not  known, 
ELEX-560  proposed  an  Indefinite  Delivery,  Requirements  type 
contract.  Competition  would  be  based  on  unit  price  per  lot 
quantity  for  a  specified  system  configuration  plus  prices  of 
certain  add-on  modules.  By  mid-November  1972,  25  firms  had 
indicated  a  desire  to  submit  proposals  and  none  were  thought 
to  be  unresponsive.  A  fully  competitive  procurement  seemed 
assured. 

The  RFP  released  on  1  December  1972  cited  the  milestones 
previously  listed  and  a  three  year  production  run.  Each 
year's  production  was  an  option  to  be  priced  separately  so 
that  the  contractor  could  protect  himself  from  inflation. 
The  RFP  contained  estimated  production  requirements  for  each 
year  to  protect  the  contractor  from  the  high  risks  of 
bidding  on  unknown  production  quantities.   Production   funds 
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would  be  obtained  directly  from  the  users  at  the  time  they 
placed  orders  under  the  annual  Requirements  Contracts.  The 
RFP  also  specified  a  government  option  for  rights  to  the 
technical  data  to  provide  for  a  competitive  follow-on 
procurement. 

At  this  point  some  comments  should  be  made  about  the 
acquisition  strategy.  First,  a  great  deal  of  the  success 
hinged  on  obtaining  adequate  competition.  Without  it,  there 
would  be  little  to  choose  from  as  far  as  system  design  and 
price.  Second,  the  desire  to  select  the  lowest  bidder 
precluded  opting  for  a  better  design  at  a  slightly  higher 
acquisition  cost,  thus  achieving  better  performance  and 
reliability  and  possibly  a  lower  overall  life-cycle  cost. 
Third,  unless  later  funding  for  the  standard  minicomputer 
project  was  forthcoming  from  Operations  &  Maintenance  Navy 
(O&MN)  appropriated  funds,  the  users  would  bear  the  costs  of 
support  software  maintenance  and  enhancements,  system 
improvements,  maintenance  of  documentation  and  other  support 
costs.  This  was  a  point  that  worried  user  project  managers. 
Put  simply,  if  the  orders  stopped  the  funding  would  stop, 
and  the  system  would  no  longer  be  supported. 

By  the  end  of  December  1972  the  estimated  award  date  had 
slipped  to  1  March  1973  because  of  changes  to  the  RFP. 
Those  changes  resulted  from  substitution  of  the  CVTSC 
project  requirements  for  the  Mk68  GFCS  requirements  when  the 
latter  projects  funds  were  cut.  At  that  time  there  were 
also  growing  complaints  from  interested  companies  that  the 
RFP  closing  date  was  too  soon,  the  specification  was  too 
restrictive,  and  the  delivery  date  for  FDM's  was 
unrealistic.  Because  of  these  points,  plus  the  unspoken 
consensus  that  the  specification  favored  one  company^ 
design  philosophy,  about  19  of  the  original  25  interested 
firms  declined  to  submit  proposals.  Included  in  these  19 
were  IBM  Corporation,  Rolm  Corporation,  Control  Data 
Corporation  (CDC) ,  and  Digital  Equipment  Corporation  (DEC) . 
The  competition  was  rapidly  vanishing. 
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The  options  open  to  the  Navy  at  this  point  were  as 
follows: 

*  Maintain  the  schedule  despite  the  high  probability  of 
a  sole-source  procurement. 

• 

*  Slip  user  project  schedules  in  order  to  extend  the 
proposal  due  date  and  gain  more  competition. 

*  Cancel  the  RFP  and  restructure  the  procurement  as  a 
development  effort. 

The  decision  was  to  slip  the  closing  date  for  receipt  of 
proposals  to  2  April  1973  and  extend  the  date  for  delivery 
of  FDM*s  to  120  days  after  date  of  contract.  Since  this 
schedule  might  not  meet  some  potential  user  schedules,  a 
risk  of  losing  some  firm  requirements  had  been  accepted. 

During  the  month  of  February  1973  two  formal  protests  on 
the  RFP  were  filed  with  the  Government  Accounting  Office 
(GAO) .  The  first,  from  Control  Data  Corporation,  was 
satisfied  by  the  extension  of  the  due  date  for  proposals. 
The  second,  from  UNIV&C,  objected  to  the  extension  on  the 
grounds  that  the  company  had  spent  considerable  effort  and 
funds  to  meet  the  original  dates.  An  important  point 
brought  out  in  this  latter  protest  was  that  no  firm  had  a 
computer  that  would  meet  the  specification  completely,  and 
that  substantial  design  and  development  effort  were 
necessary  in  all  cases.  SAO  subsequently  determined  that  no 
violation  of  procurement  law  had  occurred,  and  UNIVAC's 
protest  was  denied. 

Although  not  required  for  a  procurement  of  such  low 
estimated  dollar  value  ($1.8  million),  a  Source  Selection 
Authority  (SSA) ,  Source  Selection  Advisory  Council  (SSAC) , 
and  Source  Selection  Evaluation  Board  (SSEB)  were 
designated.  The  SSEB  consisted  of  the  DRG  plus 
representatives  of  NAVELEX,  the  Marine  Corps  and  TADSO.  The 
SSAC  consisted  of  representatives  of  NAVELEX  and  TADSO   with 
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expertise  in  management  systems,  cost  analysis,  logistic 
support,  etc.  The  SSA  was  COMNAVELEX  with  the  advice  and 
consent  of  CNM. 

On  2  April  1973  proposals  were  received  from  UNI7AC, 
CDC,  General  Electric  and  Raytheon.  The  SSEB  proceeded  to 
evaluate  the  proposals  without  knowledge  of  prices  and  found 
all  firms  to  be  responsive  to  the  DRG  specification.  The 
SSAC  determined  that  adeguate  price  competition  existed.  A 
pre-award  survey  was  conducted  at  each  plant  during  the  week 
of  16  to  20  April  1973.  All  offerers  were  found  to  be 
technically  and  financially  responsible  and  responsive  in 
accordance  with  Armed  Services  Procurement  Regulation  (ASPR) 
1-903.  Contract  award  was  made  to  the  low  bidder,  UNIVAC, 
on  27  April  1973.  The  contract  included  all  hardware 
reguirements  plus  an  assembler  for  a  f irm-f ixad-price  of 
$673,000. 

Soon  after  contract  award,  user  reguirements  for 
additional  support  software  in  addition  to  the  assembler 
were  identified.  To  meet  this  need,  sole-source  contracts 
were  let  to  ONIVAC  for  two  self-hosted  systems.  The  first, 
designated  Level  I,  was  released  in  November  1973.  The 
second,  designated  Level  II,  was  released  in  January 
1974. [App.  G]  NAVELEX  also  contracted  with  UNIVAC  at  that 
time  to  develop  two  other  support  software  packages:  a 
standard  real-time  executive  later  designated  SDEX-20,  which 
was  to  provide  users  with  basic  software  modules  upon  which 
to  build  their  operational  programs;  and  a  compiler  for  the 
Navy  standard  high-level  language  (CMS-2) ,  which  would 
generate  machine  code  for  the  UYK-20.  This  high-level 
language  for  the  UYK-20  was  designated  CMS-2M  and  was  to  be 
a  subset  of  the  CMS-2  language.  These  additional  contracts 
were  funded  from  the  balance  remaining  of  $1.3  million  in 
RDT&EN  funds  reprogrammed  for  the  UYK-20  acguisition. 

In  May  1973  TADSO  revised  TADSTAND  1  to  designate  the 
UYK-20  as  the  Navy  Standard  digital  processor  for  those 
applications  requiring  a  minicomputer.  [Ref.  3  ]  As  expected, 
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this  action  generated  a  few  requests  for  deviation  from  that 
standard.  Most  were  turned  down.  The  Submarine  Integrated 
Radio  Room  (IRR)  project,  which  was  developing  with  the  CDC 
MPP  computer  and  the  AN/UYK-15  (V) ,  had  a  request  to  deviate 
denied  on  the  basis  that  the  OYK-20  was  upward  compatible 
with  the  OYK-15.  Very  few  requests  for  deviation  were 
granted.  The  VERDIN  retrofit  project  was  granted  a  waiver 
due  to  size  problems  in  retrofitting  equipment  into  a 
submarine,  and  the  necessity  for  compatibility  with  existing 
equipments.  The  SEA  SCOOT  project  was  granted  a  waiver 
since  two  systems  were  already  deployed  with  the 
AN/OYK-12  (V)  ,  urgent  requirements  existed  for  four  more 
systems,  and  no  more  than  a  total  of  six  systems  were  to  be 
acquired.  The  BOLLSEYE  project  was  granted  a  waiver  to  use 
the  DEC  PDP-11  computer  as  its  shore-site  cryptologic 
processor.  Justification  for  that  waiver  was  that  the 
PDP--11  was  currently  in  use  at  shore  sites,  associated 
engineers  and  support  systems  were  available,  and  shipboard 
use  was  not  anticipated. 

On  27  March  1974  the  OYK-20  received  service  approval. 
A  major  milestone  in  any  program,  this  event  also  had  a 
profound  impact  on  the  funding  of  the  project.  Once  service 
approval  was  received,  the  activities  of  ELEX-560  could  no 
longer  be  supported  with  RDT&EN  funds.  Since  no  Operations 
&  Maintenance  Navy  (O&MN)  funds  were  available  to  support 
the  project,  NAVELEX  was  forced  to  assess  users  of  the 
system  for  system  support  in  the  following  manner.  The 
DYK-20  contract  was  a  Requirements,  Indefinite  Delivery 
contract  which  allowed  the  users  to  purchase  systems  and 
components  by  transmitting  a  DD  Form  1155  (Order  for 
Supplies  or  Services)  to  ELEX-560  with  an  order  form 
attached.  The  user's  funds  were  obligated  via  tha  DD  Form 
1155,  and  the  order  form  provided  a  detailed  description  of 
the  equipment  and  software  requested.  The  user  obligated 
funds  according  to  a  published  price  list.  These  published 
prices  included  a  surcharge  over  the   fixed   prices   in   the 
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contract;  it  was  this  surcharge  which  was  used  to  fund 
ELEX-560  support  activities. 

Occasionally  users  would  require  new  system  components 
(e.g.  bootstraps,  I/O  interfaces,  and/or  peripheral  handler 
software  routines  for  a  unique  peripheral  device)  . 
Naturally  the  requesting  user  had  to  provide  funds  for  the 
development  of  his  unique  requirement.  This  was 
accomplished  by  submitting  a  DD  Form  1149  (Requisition  and 
Invoice/Shipping  Document)  to  ELEX-560  with  a  description  of 
the  needed  material.  ELEX-560  would  use  the  authority 
transmitted  by  the  DD  Form  1149  to  obligate  the  user's  funds 
on  a  sole-source  Time  and  Materials  type  contract  with 
ONIVAC  for  the  development  effort. 

Accounting  for  the  surcharge  and  the  myriad  of 
appropriation  budget  activities  cited  by  the  users  was  an 
elaborate  task.  Frequent  liason  with  ordering  activities 
was  necessary  to  insure  that  surcharges  were  "paid"  out  of 
appropriation  catagories  which  could  be  properly  used  by 
ELEX-560.  For  the  most  part  O&MN  funds  were  required  to 
fund  project  tasks. 

The  surcharge  systam  concerned  user  project  managers. 
Primary  objections  were  (1)  the  necessity  to  pay  prices 
above  the  fixed  prices  on  the  contract,  and  (2)  the 
realization  that  if  no  orders  were  received  the  funding 
support  for  the  project  would  dry  up.  Each  year  NAVZLEX 
requested  sufficient  O&MN  funding  to  support  the  project, 
but  those  funds  were  never  forthcoming.  Project  personnel 
believed  that  the  project  requirements  were  cut  from  the 
Navy  budget  submission  by  the  Office  of  the  Secretary  of 
Defense  (OSD)  or  the  Office  of  Management  and  Budget   (OMB) . 

In  September  1974  the  first  issue  of  "The  Standard"  was 
published.  This  document  was,  as  stated  in  its  header,  "a 
bi-monthly  newsletter  published  to  inform  AN/UYK-20  users  of 
current  status  and  new  developments  that  involve  the 
AN/UYK-20  (V)  computer  and  its  support  software."  "The 
Standard"  was  a   step   toward   solving   the  communications 
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>roblem  that  plagues  all  bureaucratic  organizations. 

About  that  same  time  the  idea  of  a  formal  user's 
>rganization  was  conceived,  and  in  November  1974  the  first 
kN/UYK-20  User's  Group  meeting  was  held  at  the  Naval 
Slectronics  Laboratory  Center  (NELC)  in  San  Diego.  The 
neeting  attracted  some  200  persons  from  government  and 
private  industry.  By  mid-1976  the  AN/UYK-20  User's  Group 
*as  meeting  semi-annually  in  the  Spring  and  Fall  and  boasted 
i  membership  of  close  to  300  persons.  Each  meeting  provided 
a  forum  for  ELEX-560  to  transmit  further  information  to  the 
jsers,  but  more  importantly  for  the  users  to  present  ideas 
in  briefings  and  presentations  which  would  benefit  other 
users.  The  meetings  also  provided  an  opportunity  for  users 
and  project  cffice  personnel  to  meet  face  to  face  and 
liscuss  problems. 

At  the  November  1976  (Jser's  Group  meeting  at  the  Naval 
Postgraduate  School  in  Monterey,  the  Fleet  Combat  Direction 
Systems  Support  Activity  (FCDSSA)  San  Diego  announced  the 
release  of  a  compiler  for  the  UYK-20  computer.  This 
compiler,  designated  CMS-2Y(20),  operated  under  the  SHARE/7 
operating  system  on  the  AN/UYK-7  computer.  The  compiler  was 
designed  to  provide  versatile  program  development 
capability,  since  it  utilized  the  powerful  programming  aids 
available  under  SHARE/7.   [App.  G] 

By  late-1974  the  first  UYK-20  computers  had  been 
received  and  were  in  use  in  the  development  of  tactical 
systems.  Many  hardware  failures  were  encountered  in  these 
early  computers.  The  hardware  problems  were  compounded  by 
the  fact  that  the  diagnostic  program  package  for  the  UYK-20 
was  not  available  to  users  until  November  1974.  Users  were 
dependent  on  UNIVAC  field  engineers  to  perform  corrective 
maintenance.  Errors  were  also  encountered  in  the  support 
software  and  in  the  documentation  for  both  hardware  and 
software.  In  general  these  problems  were  discovered  and 
solved  through  trial  and  error,  but  with  large  expenditures 
of  user  time  and  funds. 
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The  types  of  problems  most  often  encountered  during  the 
early  period  in  late-1974  were:  Memory  Array  Board  failures, 
Memory  Control  Board  failures,  broken  or  bent  connection 
pins  on  printed  circuit  (PC)  cards,  defective  power 
supplies,  PC  cards  not  seated  properly,  and  software 
documentation  which  either  contained  erroneous  descriptions 
of  software  capabilities  or  neglected  to  mention 
capabilities  that  existed.  The  contractor,  who  was 
responsible  for  correcting  many  of  the  problems,  submitted 
Engineering  Change  Proposals  (ECP's)  to  NAVELEX  to  correct 
deficiencies.  Because  of  a  clause  in  the  contract  which 
required  all  production  units  to  be  identical,  a  retrofit 
was  necessary  to  incorporate  the  approved  Engineering 
Changes  into  production  units  already  in  the  field.  UYK-20 
serial  number  350,  which  came  off  the  production  line  in 
December  1975,  became  the  baseline  unit  for  the  first 
retrofit.  All  349  previous  production  units  were  affected 
in  varying  degrees.  Retrofit  I  consisted  of  minor  changes 
such  as  replacement  of  screws,  mountings,  and  fittings,  and 
major  changes  such  as  replacement  of  power  supplies  in 
serial  numbers  1  through  12,  replacement  of  PC  cards  which 
had  been  redesigned,  and  modifications  to  existing  cards. 
The  retrofit  was  performed  in  the  field  by  UNIVAC  engineers 
during  the  period  from  January  1975  to  September  1976. 

Despite  the  discovery  and  correction  of  many 
deficiencies,  by  mid-1975  the  frequency  of  failures  in 
production  units  signified  that  a  reliability  problem  did 
exist.  Perhaps  the  best  data  base  attesting  to  the 
suspected  reliability  problems  came  from  the  Naval 
Electronics  Systems  Engineering  Center  (NESEC)  at  San  Diego. 
This  activity  was  tasked  with  assembly  and  checkout  of  the 
Navy  Message  Address  Communications  System  (NAVMACS) ,  which 
was  one  of  the  first  systems  using  UYK-20  to  reach  the 
fleet.  During  the  period  late-1974  to  mid-1975,  NESEC  San 
Diego  reported  that  a  high  percentage  of  production  units 
were   received   inoperative   due   to   faulty   PC   cards  and 
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assembly  modules.  Spares  received  were  also  defective, 
making  trouble-shooting  with  the  diagnostic  programs  very 
difficult.  (Trouble-shooting  procedures  utilizing  the 
diagnostic  routines  depended  on  substituting  spare  modules 
and  PC  cards  for  suspected  defective  parts.)  Some  failures 
were  intermittant ,  making  them  extremely  difficult  to 
diagnose. 

Records  at  NESEC  San  Diego  indicate  that  during  the 
period  late-1974  to  mid-1975  many  modules  were  experiencing 
60%  to  70%  failure  rates.  Particular  problem  areas  were 
power  supplies,  Memory  Array  Boards,  seating  of  I/O  cards, 
and  overheating  in  hot  weather.  It  was  found  that  over  a 
significant  period  of  operation,  however,  the  failure  rate 
would  be  substantially  decreased,  indicating  that  a 
"burn-in"  period  increased  reliability. 

In  response  to  the  reports  from  NESEC  San  Diego, 
personnel  from  UNIVAC  visited  that  activity  and  verified  the 
need  to  upgrade  reliability.  In  June  and  July  of  1975 
UNIVAC  voluntarily  shut  down  the  production  line  in 
Clearwater,  Florida  to  investigate  the  possibility  of  severe 
Quality  Assurance  (QA)  problems.  Over  the  ensuing  months 
the  contractor  took  the  following  action  to  up-grade  UYK-20 
quality: 

*  Personnel  Improvements 

■  Established  QA  as  an  independent  organization. 

■  Transferred  added  QA  technical  and  management 
capability  from  the  main  plant  in  St.  Paul, 
Minnisota  to  the  UYK-20  production  plant  in 
Clearwater. 

■  Hired  additional  quality  engineers  and 
inspectors. 

■  Added  a  program  QA  man  in  Clearwater. 

■  Transferred  final  testing  to  Manufacturing  in 
order  to  remove  schedule  concerns  and  increase  QA 
focus. 
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*  Documentation  and  Procedures 

■  Reviewed   and   updated   all   inspection   and  test 
procedures. 

•  Established   formal   procedures  for   resolving 
Defense  Contract   Administration   Service   (DCAS) 
and  ONIVAC  quality  concerns  and  for  implementing 
corrective  actions. 

■  Reviewed  and  improved  assembly  processes. 

■  Added  automatic  equipment. 

■  Introduced  new   material  handling  containers  for 

PC  cards. 

■  Developed   new  fixtures  for  holding  memory  arrays 
during  assembly. 

*  Training  and  Motivation 

■  Hired  a  full-time  trainer. 

■  Established  a  dedicated  training  room. 

■  Instituted  training   programs   for  manufacturing 
and  inspection  personnel. 

■  Established    certification     criteria     and 
recertif ication   time  periods  for  all  key  skills. 

*  Management  Reviews 

■  Increased  local  audits. 

■  Established  formal   defect   trend  reviews   with 
manufacturing  and  QA. 

■  Implemented  corrective  action   follow-up   on  key 
defects. 

■  strengthened  and  increased  management  audits. 

After  the  June  to  July  shutdown  and  the  subsequent 
quality  improvement  program,  UNIVAC  experienced  a  66% 
improvement  in  acceptance  tests  at  the  Clearwater  plant. 
These  improvements  were  felt  by  the  users  in  late- 1975  when 
a  high  percentage  of  computers  received  from  the  factory 
were  in  operational  condition. 
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In  late-1974,  in  response  to  user  demands,  Onivac 
developed  a  User's  Handbook  for  the  AN/OTK-20  (V)  DPS.  This 
handbook  was  written  primarily  for  operational  program 
development  programmers  and  contained  a  description  of  the 
hardware  and  detailed  descriptions  of  support  software.  The 
handbook  was  first  released  in  early-1975  and  by  mid-1976 
had  undergone  four  major  revisions  to  correct  numerous 
errors  and  incorporate  new  software  systems. 

Early  in  1975  SDEX-20  (the  Standard  Real-Time  Executive) 
and  the  CMS-2M  compiler  were  released.  Since  CMS-2M  was  a 
subset  of  the  CMS-2  standard  high-level  language,  it  became 
a  standard  also.  OYK-20  users  were  required  to  write  their 
operational  programs  in  that  language.  A  few  projects  had 
begun  development  using  other  languages,  pradominantly 
FORTRAN,  and  were  unwilling  to  rewrite.  Their  objections 
cited  schedule  impact,  increased  development  cost  and  the 
high  risk  associated  with  using  an  untested  compiler.  TADSO 
held  a  firm  line,  and  most  projects  still  in  development 
were  forced  to  switch  to  CMS-2M. 

Op  to  the  beginning  of  1975  no  peripheral  devices 
existed  which  were  specifically  meant  for  use  in  Navy 
tactical  systems.  It  was  rapidly  becoming  apparent  that 
proliferation  of  diverse  peripheral  equipments  was  also  a 
problem.  By  May  1975,  76  unique  peripheral  devices  were  in 
use  with  the  OYK-20  computer.  In  February  and  March  of  1975 
two  contracts  were  let  for  peripheral  devices  which  were 
destined  to  become  standards  for  use  in  Navy  systems: 

*  A  contract  with  QOANTEX,  Peripherals  Division  of 
North  Atlantic  Industries  Incorporated  for  a 
Cartridge  Magnetic  Tape  Onit  (CMTO)  which  was 
eventually  designated  AN/OSH-26  (V) . 

*  A  contract  with  ONIVAC  for  an  Alphanumeric  Display 
Device  (ADD) ,  which  was  eventually  designated 
AN/OSQ-69 (V) . 
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The  acquisition  strategy  for  these  peripheral  units  was 
identical  to  that  utilized  in  the  standard  minicomputer 
procurement.  Requirements,  Indefinite  Delivery, 
firm-fixed-price  contracts  were  awarded  to  the  low  bidders 
among  those  contractors  found  responsible  and  responsive  to 
the  RFP.  The  first  standard  peripheral  production  units 
were  scheduled  to  be  delivered  in  October  1976. 

As  a  result  of  its  diversification  into  peripheral 
equipments  and  other  areas,  at  the  beginning  of  Fiscal  Year 
1976  ELEX-560  was  redesignated  the  Automatic  Data  Processing 
(ADP)  Systems  Division  (ELEX-570) .  With  the  redesignation 
came  increased  scope  of  responsibilities  including: 

*  Tactical  ADP  hardware  development. 

*  Tactical  ADP  software  development. 

*  Tactical  ADP  display  systems  development. 

* 

In  September  and  October  of  1975  the  Disk  File  Manager 
software  and  Machine  Independent  System  Generator  software 
packages  were  released.  [App.  G] 

In  November  1975,  at  the  AN/UYK-20  User's  Group  meeting, 
it  was  announced  that  a  User's  Group  Software  Directory 
would  be  published  quarterly  by  the  Publications  Chairman  of 
the  User's  Group.  This  directory  was  designed  to  inform 
users  of  the  availability  of  operational  and  support 
software  developed  by  other  users.  Although  the  concept  was 
good,  by  May  1976  there  were  no  suppliers  of  information  on 
their  software,  although  there  were  many  requests  for  the 
directory. 

Also  announced  at  the  November  1975  meeting  was  an 
AN/UYK-20  Test,  Analyse  and  Fix  (TAAF)  program.  This 
program,  to  be  carried  out  at  the  Naval  Weapons  Center  at 
Dahlgren,  was  designed  to  accomplish  the  following 
objectives: 

*  Perform  a  Navy  conducted  AN/UYK-20   reliability   test 
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to: 

■  Ensure   recently   retrofitted    field   changes 
improved  OYK-20  operation. 

■  Detect   any   additional   changes   required   to 
demonstrate  a  2000  hour  MTBF. 

*  Establish  a  OIK-23  field  data  collection  program. 

The  test  setup  was  to  cousist  of  four  machines  variously 
configured  to  excercise  all  hardware  options.  A  total  of 
12,000  hours  of  operation  under  steady-state  temperature, 
voltage  and  frequency  conditions  was  planned.  Two  of  the 
machines  were  to  be  subjected  to  a  total  of  600  hours  of 
vibration  testing.  In  May  1976  the  results  of  the  TAAF 
program  were  reported  to  the  Oser's  Group  assembled  at  the 
Naval  Underwater  Systems  Center  in  New  London.: 

*  Corrective  Action  Items  Identified 

■  Memory   Array   Board  fabrication  popped  resistors 
and  cracked  cores. 

•  The  master  clock  was  overloaded. 

■  Miscellaneous  logic  gates  were  overloaded. 

■  A  certain  type   of   Read-Only-Memory   (ROM)  was 
defective  and  should  be  replaced. 

*  Corrective  Action  items  Installed 

■  An  Engineering    Change   to   eliminate   clock 
overload. 

a  Increased  QA  inspection  of   Memory  Array   Boards 
and  Power  Supplies. 

*  Observations 

■  No  component  reliability  problems  were  detected. 

■  Reliability  agreed  closely  with   available   field 
data. 

■  Failures   were   due   to   fabrication   techniques, 
design  problems  and  normal  component  failure. 
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The  data  gathered  during  the  TAAF  program  showed  that  MTBF 
during  the  first  4000  hours  of  operation  on  the  four 
machines  remained  low  at  about  500  to  600  hours.  After  4000 
hours  a  steady  improvement  occurred  so  at  the  completion  of 
testing  (12,000  hours)  the  MTBF  was  about  1500  hours.  The 
results  of  these  formal  tests  essentially  confirmed  what  had 
been  suspected  by  users  a  year  and  a  half  previously  -  that 
memory  boards  and  power  supplies  were  a  major  cause  of 
failures,  and  that  a  significant  "burn-in"  period  was 
necessary  for  reliable  operation. 

By  the  end  of  1975  many  design  deficiencies  had  been 
corrected  through  Engineering  Changes.  The  contractor  had 
also  requested  waivers  on  certain  deficiencies  which  he 
thought  too  rare  to  warrant  attention.  ELEX-570  approved 
two  of  those  requests  for  deviation  from  the  design 
specifications:  circuit  breaker  trip  under  shock  test,  and 
Electromagnetic  Interference  (specifically  magnetic 
radiation)  test  results.  All  other  requests  had  been 
refused,  but  by  the  end  of  1975  the  contractor  had  failed  to 
correct  three  deficiencies: 

*  The  NTDS  serial  I/O  interface  was  experiencing  signal 
reflections  when  cable  lengths  of  150  to  225  feet 
were  used. 

*  Dnder  certain  conditions  the  condition  code  was  not 
set  properly  during  double  precision  subtract 
operations. 

*  Onder  certain  conditions  Floating  Point  Add/Subtract 
operations  resulted  in  errors. 

As  a  result,  the  government  stopped  accepting  production 
units  from  December  1975  to  February  1976.  This  firm  action 
caused  the  contractor  to  submit  ECP's  to  correct  the  three 
deficiencies. 

Computer   serial   number   550,   which   was   produced   in 
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February  1976,  became  the  base-line  for  a  second  retrofit. 
Retrofit  II  implemented  the  Engineering  Changes  to  correct 
the  three  design  deficiencies  listed  above  plus  six  others. 
(About  90  Engineering  Change  Proposals  had  been  submitted  by 
that  time.) 

Naturally,  the  two  shutdowns  put  UYK-20  production 
behind  schedule.  At  the  User's  Group  meeting  in  May,  1976 
it  was  reported  that  824  units  had  been  ordered,  but  only 
637  delivered. 

At  the  same  User's  Group  meeting  ELEX-570  reported  the 
establishment  of  an  AN/UYK-20  Support  Software  Repository. 
The  purpose  of  the  repository  was  to  collect  and  distribute 
as  required  to  U.  S.  Government  UYK-20  users,  software 
developed  by  other  U.  S.  Government  users.  This  effort  was 
designed  to  reduce  software  development  redundancy  and  thus 
reduce  development  costs.  Also  reported  to  the  User's  Group 
was  the  impending  release  of  a  new  technical  manual,  the 
first  major  revision  of  this  document. 

This  chapter  has  related  the  growing  pains  of  a  computer 
system  from  development  through  initial  production.  Many  of 
the  problems  were  to  be  expected  in  such  a  project.  The 
unfortunate  part  of  the  UYK-20  history  was  that  throughout 
this  growth  period  users  were  dependent  on  the  computer  as  a 
component  in  tactical  systems  under  development.  The  early 
unreliability  of  this  component  compounded  the  problems 
encountered  in  developing  those  systems.  The  next  chapter 
will  discuss  the  impact  of  the  UYK-20  computer  on  user 
systems  during  this  period  of  growth. 
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IV.   EVALUATION  OF  THE  SYSTEM 

The  previous  chapters  have  been  historical  in  nature, 
relating  the  events  which  marked  the  development  and  initial 
production  run  of  the  standard  minicomputer.  It  is  the 
purpose  of  this  chapter  to  evaluate  the  system  itself  and 
the  impact  of  UYK-20' s  growing  pains  on  the  development  of 
those  systems  which  used  it  as  a  system  component. 


A.   COMPARISON  OF  SPECIFICATION  AND  FINAL  PRODUCT 

Chapter  II,  Section  C  and  Appendix  B  discussed  the 
specification  upon  which  the  AN/UYK-20  DPS  acquisition  was 
based.  To  complete  the  historical  picture  presented  in 
previous  chapters,  it  is  necessary  to  briefly  discuss  the 
actual  product  which  resulted  from  the  standard  minicomputer 
acquisition.  For  ease  of  comparison,  App.  H  summarizes  the 
characteristics  of  UYK-20  as  it  existed  at  mid-year  1976. 
Appendix  B  summarizes  the  DRG*s  specification.  Appendix  I 
lists  the  basic  hardware  configuration  and  options 
available.  Appendix  G  describes  the  system  support 
software.   References  16  and  17  provide  further  dstails. 

By  comparing  Apps.  B  and  H  it  can  be  seen  that  the 
UYK-20  system  met  or  exceeded  the  specification  in  all  major 
areas  except  reliability  and  maintainability.  As  discussed 
in  the  previous  chapter,  MTBF  to  2000  hours  has  never  been 
demonstrated.  No  empirical  data  on  MTTR  was  available.  It 
must  be  remembered  that  MTTR  included  localization  of  the 
problem,  correction,  alignment  and  calibration,  and  system 
checkout.  It  could  be  pastulated  that  meeting  an  MTTR  of  15 
minutes  presumed  that  the  diagnostic  programs  were  ready  to 
load  (via  magnetic  tape  or  paper  tape) ,  that  the   technician 


54 


was  familiar  with  the  diagnostic  procedures  published  in  the 
Technical  Manual,  and  that  a  complete  spares  kit  was 
available.  If  the  trouble  was  isolated  to  a  module  which 
was  missing  from  the  spares  kit,  the  MTTR  would  necessarily 
include  time  to  procure  the  part. 

The  UYK-20  represented  improvement  over  the 
specification  in  the  areas  of  speed,  number  of  general 
registers,  instruction  repertoir,  weight  and  power 
consumption.  Weaknesses  were  in  the  memory  addressing 
scheme  and  interrupt  structure.  Some  weaknesses  in  the  I/O 
structure  were  discussed .  in  Chapt.  II.  In  addition,  the 
Central  Processor  (CP)  and  the  I/O  Controller  (IOC)  ended  up 
sharing  the  same  memory  port,  with  the  IOC  having  priority 
over  the  CP.  An  optional  Direct  Memory  Access  (DMA)  channel 
was  provided,  which  accessed  memory  through  a  second  memory 
port.  This  minimized  interference  between  the  CP/IOC  and 
the  DMA  device,  but  the  addition  of  the  DMA  capability  added 
about  65  nanoseconds  to  the  memory  cycle  time.  An 
additional  drawback  was  that  the  CP/IOC  had  priority  over 
the  DMA  in  accessing  any  particular  memory  bank.  Since  many 
accesses  are  sequential,  .  the  CP  could  lock-out  the  DMA 
device  from  memory.  Although  it  was  not  mentioned  in  the 
documentation,  a  jumper  connection  on  a  PC  card  could  be 
modified  to  give  the  CP/IOC  and  DMA  memory  ports  equal 
priority. 

There  was  no  provision  to  expand  main  memory  beyond 
65K-words. 

Although  multi-level  indirect  addressing  was  possible, 
the  procedure  for  implementation  was  awkward  and  involved 
setting  indirect  control  bits  in  a  status  register  and 
storing  information  in  an  Indirect  Word. 

Sixty-four  page  registers  existed  so  that  main  memory 
could  be  divided  into  64  blocks  of  1,024  words  each.  No 
memory  protection  existed,  however,  which  was  necessary  to 
prevent  inadvertant  access  to  pages  in  memory  by 
unauthorized  programs.   Also  missing  was  a  provision   for   a 
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privileged  state  (i.e.  a  set  of  privileged  instructions 
which  could  be  reserved  for  use  by  a  designated  executive 
program.     The    lack   of   those   latter   two   capabilities 

prevented  the  efficient  implementation  of  program  swapping 
algorithms  for  multi-programming  applications.  Z  z,~ 
usefulness  of  the  page  registers  was  thus  limited. 

The  interrupt  structure  weakness  primarily  involved  the 
inability  to  nest  interrupts.  If  an  interrupt  from  one 
class  was  interrupted  by  an  interrupt  from  another  higher 
priority  class  (there  were  three  classes) ,  the  lower 
priority  interrupt  would  be  saved  while  the  higher  priority 
interrupt  was  processed.  However,  only  one  storage  area  for 
saving  status  registers,  program  registers  and  real-tine 
clock  existed  per  interrupt  class.  If  an  interrupt 
pre-empted  another  interrupt  of  the  same  class,  tae  saie 
storage  area  would  be  reused  and  the  previous  program  status 
would  be  lost  forever. 

The  instruction  repertoir  was  extensive,  reflecting  the 
capabilities  of  microprogrammed  control.  Instruct icr.s  were 
incorporated  from  the  AN/OYK-15 (7)  instruction  set  to  ma'.e 
the  OTK-20  upward  compatible  with  that  machine.  Although 
not  required  by  the  specification,  significant  capability 
for  floating-point,  mathematical  and  trigonometric  functions 
existed  in  an  optional  module  cf  microprogram  routines 
designated  the  MATHPAC.  Also  a7~i_5.nie  as  an  option  was  512 
words  of  user  specified  microprogram  routines,  designated 
the  Hicrogrowth. 

By  1976  there  was  available  an  extensive  set  of  support 
software  [App.  G],  but  it  must  be  remembered  that  the  first 
systems  only  had  an  assembler  program.  The  rest  of  tie 
software  was  developed  over  the  ensuing  tnree  fears. 
Significant  also  was  the  fact  that  «r3P  was  much  worse  in 
the  early  months  than  the  1500  hours  demonstrated  in  1976. 

This  section  has  briefly  compared  the  AI/UTK-2C  DPS  -itn 
the  DRG's  specification.  In  general  more  capability  existed 
in  the  final  product  than   was  originally   requested,   with 
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some  important  exceptions.  Ensuing  discussions  will  compare 
the  UYK-20  with  the  "off-the-shelf"  state-of-the-art  in 
minicomputer  design  in  late-1 972/early-1973.  The 
discussions  will  provide  further  insight  into  the  true 
capabilities  of  the  AN/UYK-20  DPS. 


B.   COMPARISON  OF  AN/UYK-20  DPS  WITH  THE  1972 
"OFF-THE-SHELF"  MINICOMPUTER  STATE-OF-THE-ART 

It  has  been  stated  previously  that  the  standard 
minicomputer  specification  may  have  been  too  restrictive. 
If  given  the  funding  constraints,  the  acquisition  strategy 
had  embodied  design-to-cost  concepts,  for  example,  so  that 
the  proposals  could  work  toward  the  best  system  for  the 
money  guided  by  a  performance  specification,  the  final 
product  may  have  looked  much  different.  It  would  be 
difficult  to  postulate  the  cost  of  militarizing  any 
particular  commercially  marketed  computer  system.  It  is 
beyond  the  scope  of  this  thesis  to  predict  what  the 
proposals  would  have  been,  given  the  development  funds  and 
production  prices  eventually  realized.  This  section  will, 
however,  discuss  the  technical  possibilities  available  in 
late-1972  and  early-1973.  The  intent  is  to  consider  that 
state-of-art  which  was  through  development  and  into 
production  about  the  time  of  the  standard  minicomputer 
Request  for  Proposals  (RFP) .  The  assumption  is,  as 
previously  stated,  that  the  Navy  wanted  to  minimize  time  and 
development  effort  and  so  would  look  for  a  system  which  was 
ready  for  market.  The  discussions  will  also  provide  a 
further  means  of  evaluating  the  AN/UYK-20  DPS.  For 
information,  four  minicomputers  representing  the  1972 
technology  are  profiled  in  Apps.  J  through  M. 

1 .   Architecture 

Certainly  the  microprogrammed  processor  was  the  most 
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common  architecture  in  1972  minicomputers.  Of  the  four 
examples,  only  the  Digital  Equipment  Corporation  PDP-11/45 
was  not  microprogrammed.  Microprogramming  permitted  a 
reasonably  powerful  instruction  repertoir  while  minimizing 
size  and  electrical  power  consumption.  Basically  two  types 
of  microprogramming  were  used.  Horizontal  microprogramming 
utilized  a  long  micro-instruction  word  where  each  bit 
controlled  a  specific  register-transfer  function.  The 
Varian  73  with  a  64-bit  micro-instruction  word  was  a  good 
example  of  that  design  concept.  The  Rolm  1602  with  a  32-bit 
micro- instruction  word  was  a  border  line  case.  Vertical 
microprogramming  utilized  shorter  micro-instruction  words 
which  required  some  hardware  decoding  in  the  control 
process.  The  Hewlett  Packard  2100A  with  a  24-bit 
micro-instruction  word  and  the  UYK-20  with  a  16-bit 
microinstruction  word  are  examples  of  vertical 
microprogramming.  The  tradeoff  between  the  two  types  was 
more  high-speed  memory  and  simpler  hardware  logic  for 
horizontal  versus  less  memory  but  more  complex  logic  in  the 
case  of  vertical.  A  convenient  capability  in  a 
microprogrammed  processor  resulted  from  the  use  of  Writable 
Control  Store  (WCS)  memory  in  place  of  Read-Only-Memory 
(ROM) .  WCS  memory  allowed  the  user  to  alter  the 
microprograms  or  add  his  own  routines  with  the  same  ease 
encountered  in  storing  programs  in  Random  Access  Memory 
(RAM) .  By  contrast,  many  ROM  designs  involved  methods  of 
program  storage  which  were  unalterable.  Some  minicomputers 
allowed  a  mixture  of  ROM  and  WCS  in  the  control  memory. 
This  feature  was  totally  lacking  in  UYK-20,  even  in  the  User 
Microgrowth  section,  which  had  to  be  factory  produced.  To 
circumvent  this  problem,  FCDSSA  San  Diego  developed  a  device 
called  GENRAM  which  plugged  into  the  User  Microgrowth  module 
slot  of  the  UYK-20.  This  device,  along  with  a  microcode 
assembler,  facilitated  development  and  test  of  microprogram 
routines  for  the  UYK-20. 

By  contrast,  the  DEC  PDP-11/45  achieved   a   powerful 
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instruction  set  through  hardware  implemented  logic.  To  do 
so  DEC  sacrificed  size  and  power  consumption.  By  using 
high-speed  bipolar  logic  and  Large-Scale-Integration,  DEC 
achieved  much  faster  instruction  execution  speeds  than 
possible  with  a  microprogrammed  architecture.  For  example, 
an  Add  instruction  required  only  0.3  usee  contrasted  with 
0.75  usee  for  the  same  operation  in  OYK-20  or  1.96  usee  in 
HP2100A. 

Another  architecture  feature  available  on 
minicomputers  in  1972  was  register  "push-pop"  stacks.  The 
PDP-11/45  had  an  extensive  stack,  manipulation  capability, 
but  it  was  also  available  in  a  more  limited  way  on  smaller 
machines  like  the  Rolm  1602.  A  "push-pop"  stack  was  a  group 
of  registers  configured  so  that  if  a  value  was  stored  in  the 
top  register,  all  previously  stored  values  were 
automatically  "pushed"  down  to  the  register  "below".  If  the 
stack  was  referenced  by  an  instruction,  the  "top"  value 
"popped"  off  and  all  values  previously  stored  moved  "up". 
Actually  the  stack  was  implemented  through  the  use  of  a 
stack  pointer  register  which  always  pointed  to  the  "top" 
register  on  the  stack.  This  was  a  last-in-first-out  sort  of 
operation.  Stacks  were  useful  for  storing  data  that  would 
be  used  in  a  preset  order,  such  as  nesting  interrupts  where 
the  last  machine  state  (values  of  the  program  counter, 
status  registers  and  other  important  data)  were  "pushed" 
onto  the  stack,  to  be  "popped"  off  when  the  last  interrupt 
finished  processing.   The  OYK-20  had  no  stack  capability. 

Another  architecture  attribute  was  useful 
particularly  where  programs  had  to  be  swapped  on  and  off  a 
mass  storage  device  as  in  a  multi-programming  environment. 
That  attribute  was  a  Privileged  State.  Basically,  a  set  of 
instructions  was  provided  which  could  only  be  executed  while 
in  that  special  state.  Instructions  which  stopped  program 
execution,  altered  memory  assignments  of  programs,  altered 
memory  protection,  etc.  would  be  part  of  a  privileged 
instruction  set.   Combined  with  features  like  memory  protect 
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and  paging  hardware,  the  existence  of  a  privileged  state 
allowed  powerful  and  efficient  program  swapping  algorithms 
to  be  implemented.  A  privileged  state  was  generally  found 
only  on  larger  machines  like  the  PDP-11/45. 

2«   Main  Memory 

Main  memory  generally  was  available  in  thr'ee  types: 
magnetic  core.  Metal  Oxide  Semiconductor  (MOS)  and  bipolar 
semiconductor.  Core  memory  ranged  in  memory  cycle  speeds 
from  0.6  usee  to  1.5  usee  while  semiconductor  memories 
realized  memory  cycle  speeds  down  to  about  0.3  usee.  The 
tradeoff  was  that  semiconductor  memories  were  volatile, 
reguiring  additional  power  to  refresh  the  data  stored. 
Power  failure  would  result  in  the  loss  of  all  stored  data 
unless  a  backup  battery  power  source  was  provided.  Core 
memories  were  non-volatile  and  would  retain  data  for  very 
long  periods  of  time.  Core  memories  were  generally  less 
expensive  than  semiconductor,  although  LSI  techniques  were 
lowering  the  cost-per-bit  of  semiconductor  memories 
drastically.  Many  minicomputers,  such  as  the  Eolm  1602  and 
the  Varian  73,  offered  a  mix  of  memory  types. 
Communications  with  memory  were  purposely  designed  to  be 
asynchronous  (speed  independent)  to  allow  future  plug-in  of 
higher  speed  memories  as  they  became  available.  The  UYK-20 
utilized  core  memory  only.  Memory  protection  capability  and 
memory  parity  were  not  incorporated  in  the  UYK-20  for 
reasons  discussed  in  Chapt.  II,  Sect.  C.  Those  features 
were  available  on  some  minicomputers  (HP2100A  and  Varian  73) 
and  almost  always  incorporated  on  larger  computers  like  the 
PDP-11/45.  Memory  parity  was  usually  implemented  by  the 
addition  of  two  bits  per  memory  word  (one  parity  bit  for 
each  8-bit  byte) .  Memory  protect  in  minicomputers  could  be 
implemented  by  a  single  register  of  one  bit  per  memory  block 
or  by  one  or  more  boundary  registers  which  would  contain  the 
address  of  the  upper  and/or  lower  boundary  of  a  protected 
memory   block.    Most   minicomputers   offered  at   least  two 
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memory  ports  (i.e.  channels)  through  which  to  access  memory. 
The  most  common  arrangement  was  for  the  CP  to  access  memory 
through  one  port  and  a  DMA  channel  through  another  port. 
Both  the  CP  and  the  device  on  the  DMA  channel  could  access 
memory  at  memory  cycle  speeds.  HP2100A  featured  three  ports 
(two  DMA  channels  plus  CP) .  Access  speeds  of  1,000K-words 
per  second  were  typical. 

A  feature  within  the  minicomputer  state-of-the-art, 
but  not  often  implemented,  was  interleaved  memory.  This 
memory  addressing  scheme  placed  consecutive  addresses  in 
different  memory  banks  to  eliminate  one  device  locking  out  a 
particular  memory  bank  with  a  large  number  of  consecutive 
address  accesses.  PDP-11/45  featured  interleaved  memory  as 
an  option. 

The  PDP--11  family  of  computers  featured  a  unique 
architecture  attribute.  DEC  connected  all  functional 
devices  (CP,  memory  banks,  I/O  channels,  DMA  channels)  to  a 
single  data/address  bus  called  a  UNIBUS.  Each  functional 
device  was  independent  and  could  access  any  other  device  on 
the  UNIBDS  independently.  In  the  PDP-11/45  every  general 
register,  memory  location  and  I/O  register  was  given  equal 
status  as  a  location  with  an  address.  Signals  to  and  from 
all  devices  were  multiplexed  on  the  UNIBUS.  PDP-11/45 
realized  data  rates  up  to  2,500K-words  per  second  with  that 
scheme. 

3  •   Instruction  Set 

As  previously  discussed,  the  size  of  the  instruction 
set  was  highly  dependent  on  architecture.  Microprogrammed 
minicomputers  featured  far  more  powerful  instruction  sets 
than  purely  hardware  implemented  architectures.  Most 
minicomputers  offered  single  and  double-word  manipulation. 
The  HP2100A,  PDP-11/45  and  UYK-20  featured  floating-point 
instructions  as  an  option.  UYK-20  floating-point 
instruction  speeds  were  medium  compared  to  other 
minicomputers.    For   example,   for   a   floating-point    Add 
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instruction  the  times  were  HP2100A:  23.5  usee  to  59.8  usee} 
OYK-20:  7.7  usee  to  17.4  usee;  PDP-11/45:  2.4  usee  to  5.5 
usee. 

Bit  manipulation  capability  was  extensive  on  those 
minicomputers  designed  for  process  control.  For  instance, 
the  Texas  Instruments  CP-960A  was  a  bit  oriented,  rather 
than  a  word  oriented,  machine.  Some  general  purpose 
minicomputers  like  the  HP2100A  and  PDP-11/45  offered  several 
bit  manipulation  instructions  (Test  and  Set,  Compare,  Reset, 
etc.) .  OYK-20  feature!  those  basic  bit  manipulation 
functions  except  Test  and  Set  which  required  two 
instructions  -  very  awkward  in  a  real-time  programming 
environment.  Byte  manipulation  was  a  necessary  capability 
for  real-time  processing,  expecially  for  data  communications 
applications.  OYK-20  possessed  some  capability  (Load,  Load 
and  Index,  Store,  Add,  Subtract,  Compare,  Compare  and 
Index) .  The  use  of  those  byte  manipulation  instructions  was 
necessarily  awkward  since  the  OYK-20  was  a  word  oriented 
rather  than  a  byte  oriented  machine.  That  is,  each 
consecutive  address  referenced  a  full  word.  It  was 
necessary  to  indicate  by  setting  a  bit  in  a  register  which 
of  the  two  bytes  in  the  word  addressed  was  desired.  Byte 
manipulation  instructions  were  not,  however,  a  common 
feature  of  commercial  general-purpose  minicomputers. 

Another  feature  not  commonly  found  on  minicomputers 
was  the  implementation  of  trigonometric  and  hyperbolic 
functions  as  machine  instructions.  Through  MATHPAC  a  useful 
set  of  such  functions  was  available  on  OYK-20  as  an  option. 
Some  available  microprogrammed  machines  featured  extra 
control  storage  capacity  where  users  could  implement  such 
functions. 

A  capability  available  on  some  minicomputers,  but 
totally  lacking  on  OYK-20,  was  memory-to-raemory 
instructions.  That  is,  the  capability  to  perform  operations 
on  data  in  memory  and  return  the  result  to  memory  without 
first  loading  the  data   into   a   register.    Varian   73   and 
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PDP-11/45  both  featured  some  memory-to-memory  capability, 
but  in  UYK-20  all  data  had  to  be  first  loaded  into  a 
register  to  perform  further  operations. 

^ •   Input/Output 

The  most  popular  I/O  scheme  in  1972  minicomputers 
featured  a  single  I/O  bus.  In  a  single  I/O  bus  structured 
machine,  data  transfer  was  generally  controlled  by  the  CP. 
Data  rates  were  slow  (300K-  to  UOOK-words  per  second)  . 
Generally  a  number  of  peripherals  could  be  interfaced  on  the 
I/O  bus.  The  Rolm  1602  could  support  up  to  61  devices,  but 
the  HP2100A  only  14.,  Varian  73  was  also  a  single  I/O  bus 
structured  machine.  Such  machines  usually  featured  at  least 
one  DMA  channel.  The  Varian  73  featured  a  Priority  Memory 
Access  (PMA)  channel  which  allowed  data  transfers  up  to 
3,300K-words  per  second  when  semiconductor  memory  as 
installed.  A  typical  DM&  channel  data  rate  was  1,000K-words 
per  second. 

The  processor  independent  IOC  featured  on  the  UYK-20 
made  that  I/O  scheme  more  powerful  than  found  on  most 
minicomputers.  The  IOC  acted  as  an  independent  processor 
with  its  own  control  memory  and  instruction  set.  Each  group 
of  four  channels  contained  its  own  arithmetic  unit  and 
registers  and  so  could  operate  independently  once  data 
transfer  was  initiated  by  the  IOC.  One  drawback  was  that 
the  IOC  shared  a  memory  port  with  the  CP.  Another  was  that 
four  channels  shared  an  arithmetic  unit  and  registers  so 
that  all  channels  of  one  group  had  to  be  of  the  same  type. 
The  instruction  set  implemented  in  the  IOC  was  minimal. 
Data  manipulation  had  to  be  performed  by  the  CP. 

Again,  the  PDP-11/45  UNIBUS  structure  was  a  unique 
approach.  Each  peripheral  device  was  interfaced  to  the  bus 
through  its  own  independent  controller.  Thus,  every  I/O 
channel  was  a  DMA  channel.  In  addition,  each  device  could 
communicate  independently  with  another  device.  Every  device 
on  the   UNIBUS,   including  the  CP,  was  assigned  a  priority. 
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Communications  were  handled  according  to  priority  by  a 
ONIBUS  Priority  Arbitration  Unit.  By  that  system,  I/O 
transfers  were  handled  indentically  to  memory  accesses. 
Thus,  every  instruction  implemented  on  the  PDP-11/45  could 
be  used  in  an  I/O  program  to  manipulate  data. 

5»   Interrupt  Structure 

Some  1972  minicomputers  featured  a  priority 
interrupt  structure.  As  previously  discussed,  minicomputers 
with  stack  architecture  generally  featured  multi-level 
interrupt  nesting  capability.  On  other  machines  nesting  was 
accomplished  by  providing  storage  area  for  machine  status 
for  each  interrupt  line.  Two  methods  of  handling  interrupts 
were  common.  The  first  involved  branching  to  a  specific 
memory  word  assigned  to  the  interrupt,  which  contained  the 
address  of  the  interrupt  service  routine.  The  second 
allowed  a  direct  branch  to  the  interrupt  service  routine. 
The  latter  method  was  faster,  but  reguired  more  hardware 
logic.   UYK-20  implemented  the  former  scheme. 

On  UYK-20,  as  previously  discussed,  only  three 
storage  areas  were  provided  to  store  machine  status  (one  per 
interrupt  class)  so  that  nesting  capability  was  severely 
limited. 

6  •   Construction 

The  term  "modular  construction"  had  different 
connotations  with  different  manufacturers.  The  most  common 
scheme  featured  a  simple  backpanel  which  provided  only  power 
lines,  data  and  address  buses,  etc.,  which  were  common  to 
all  printed  circuit  (PC)  card  modules.  All  PC  cards  were 
the  same  size  and  could  be  plugged  into  any  slot.  Circuits 
on  a  particular  PC  card  related  to  functional  catagories, 
there  being  one  PC  card  for  the  CP,  one  for  memory  control 
circuits,  one  for  each  memory  bank,  and  one  for  each  I/O 
device  interface.  HP2100A,  Rolm  1602  and  Varian  73  were 
configured  in  that  manner.   The  PDP-11/45  also  was  similarly 
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configured,  although  backpanel  wiring  was  more  complex  due 
to  the  ONIBUS  structure.  PC  cards  were  generally  large  and 
were  structurally  reinforced  for  strength. 

UYK-20  featured  an  entirely  different  approach.  PC 
card  modules  were  utilized,  but  cards  were  small  and  were 
hardware  type  oriented  rather  than  functionally  oriented. 
For  instance,  control  memory  and  associated  circuitry 
accupied  four  PC  cards,  the  master  clock  occupied  another, 
interrupt  storage  another,  and  each  general  register  set 
(two  sets  of  16  registers  each)  occupied  a  card.  The  UYK-20 
scheme  facilitated  the  installation  of  plug-in  options  that 
were  available  [App.  I],  but  created  a  complicated  wiring 
situation  on  the  backpanel  and  greatly  increased  the  number 
of  different  types  of  PC  cards  utilized.  The  maintenance 
plan  where  a  majority  of  the  PC  cards  were  "throw-away" 
modules  (i.e.  those  cards  could  be  discarded  when  found  to 
be  defective)  also  depended  on  that  scheme.  Naturally,  a  PC 
card  containing  an  entire  processor  would  be  too  expensive 
to  discard.  The  repairable  PC  cards  in  the  OYK-20  were 
those  few  that  were  large  and  functionally  oriented  -  Memory 
Array  Boards,  Memory  Control  Boards  and  I/O  Interface  cards. 
Those  generally  were  inadequately  reinforced,  tended  to 
bend,  and  were  extremely  difficult  to  remove  and  install. 
Interestingly,  the  Holm  1602  featured  large  functionally 
oriented  cards  and  met  all  military  specification 
requirements  including  shock  and  vibration  testing.  That 
computer  was  service  approved  and  designated  AN/UYK-1 9  (V) . 

A  significant  achievement  by  Rolm  in  the  1602  design 
was  a  demonstrated  MTBF  of  11,000  hours.  Since  the  OYK-20 
experienced  significant  reliability  problems,  it  would  be 
informative  to  investigate  the  differences  in  those  two 
computers.  It  is  beyond  the  scope  of  this  thesis  to  present 
a  detailed  analysis  of  the  impact  of  the  design  and 
construction  of  the  two  machines  on  their  demonstrated 
reliability.  Some  major  points  can  be  made,  however.  The 
logic    design   itself   was   a   contributor  to   UYK-20*s 
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reliability  problems.  Por  example,  the  TAAF  program 
conducted  at  Naval  Weapons  Center  Dahlgren  revealed  that  the 
master  clock  and  certain  logic  gates  in  the  UIK-20  were 
overloaded.  A  user  reported  that  the  MIL-STD-188C 
asynchronous,  serial  I/O  interface  card  was  defective  in 
that  the  channel  would  interrupt  on  both  leading  and 
trailing  edges  of  an  interrupt  signal  pulse.  Those  were 
basic  logic  design  problems  and  would  directly  contribute  to 
module  failures.  Construction  and  reinforcement  of  larger 
PC  cards  was  inadequate  in  UYK-20.  With  frequent  handling 
such  cards  suffered  broken  components,  jumper  wires,  printed 
circuit  runs  and  connection  pins.  All  such  occurrences 
created  circuit  failures  which  lowered  MTBF.  In  a  complex 
backpanel  wiring  situation,  lack  of  adequate  quality 
assurance  measures  could  allow  wiring  errors  to  pass 
unnoticed.  Such  errors  could  appear  as  circuit  failures 
under  troubleshooting  procedures  utilizing  diagnostic 
software.  Over  the  three  years  after  contract  award,  UNIVAC 
had  corrected  many  of  those  sorts  of  problems.  let  the  MTBF 
had  risen  to  only  1500  hours.  The  reason  for  that  may  lie 
in  the  selection  and  integration  of  components.  The  ability 
for  a  manufacturer  to  control  the  quality  of  components  used 
in  producing  computers  would  directly  impact  on  reliability. 
In  producing  the  1602,  Rolm  Corporation  had  that  control. 
Most  components  in  UYK-20  were  procured  under  military 
specifications  (with  tha  exception  of  integrated  circuits) . 
Such  components  must  be  procured  from  a  Qualified  Parts  List 
(QPL)  vendor  under  military  specification  control.  In  that 
situation  UNIVAC  had  no  control  over  component  quality. 
Hardware  engineers  interviewed  generally  agreed  that  many 
components  procured  under  military  specifications  probably 
exhibited  MTBF's  in  the  hundreds  of  hours. 

7.   Support  Software 

It   is   beyond  the  scope  of  this  thesis  to  present  a 
detailed  analysis   of   the   available   minicomputer   support 
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software  in  1972.  Some  comments  can  be  made  about 
availability,  however.  As  indicated  in  Apps.  J  through  M, 
commercial  minicomputers  generally  featured  a  complete  set 
of  software.  In  most  cases  a  minicomputer  was  upward 
compatible  with  earlier  models,  so  that  each  inherited  a 
package  of  well  tested  and  fully  documented  support 
software.  New  software  nodules  could  be  added  at  leisure  to 
take  advantage  of  the  added  capabilities  of  the  more 
advanced  machine. 

Most  software  engineers  interviewed  agreed  that 
adeguate  operational  testing  was  difficult  to  achieve. 
Complete  debug  of  a  software  module  depended  on  extensive 
use  in  the  field.  Naturally,  any  software  package  inherited 
from  a  market-tested  computer  had  that  advantage. 

The  'UYK-20  computer  did  not  have  that  advantage. 
Although  upward  compatible  with  the  AN/UYK-15(V)  [App.  D], 
that  machine  did  not  possess  a  complete  package  of  support 
software  and  had  not  had  extensive  use.  Support  software 
for  UYK-20  was  developed  during  the  three  years  following 
contract  award.  As  of  mid-1976  the  CMS-2M  compiler  and 
SDEX-20  real-time  executive  were  still  in  the  "user  debug" 
stage.  All  software  was  still  receiving  enhancements  to 
upgrade  capability  as  fuQds  became  available. 

The  foregoing  material  in  this  thesis  has  discussed 
the  events  which  occurred  in  the  AN/DYK-20  DPS  acquisition 
history  and  the  technical  advantages  and  drawbacks  of  the 
system.  The  final  section  in  this  chapter  will  discuss  the 
impact  of  those  events,  advantages  and  disadvantages  on  the 
users  and  their  tactical  system  development  efforts. 


C   IMPACT  OF  AN/UYK-20  DPS  ON  DEVELOPMENT  OF  USER  SYSTEMS 

The  events  of  the  three  years  after  contract  award, 
which  have  been  referred  to  a  "growing  pains",  had  a 
significant  impact   on   the   efforts   of   users   to   develop 
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tactical  systems  utilizing   UYK-20   as  a  system  component. 

This  section  will  discuss  the  various  ways  which  that  system 

component  aided  or  complicated  those  development  efforts 

during  the  period  mid-1973  to  mid-1976. 

1.   Establishment  of  AN/UYK-20  as  a  Standard 

The  implications  of  establishing  a  "standard"  system 
component  were  discussed  in  Chapt.  II,  Sect.  B.  For  those 
programs  well  into  development  with  another  minicomputer  and 
/or  programming  language,  the  impact  on  acquisition  cost  and 
schedule  to  switch  to  UYK-20  was  significant.  One  project 
reported  a  two  year  schedule  slip  and  software  costs  of 
$350,000  to  $400,000  to  reprogram  for  the  UYK-20.  Since 
that  system  involved  primarily  data-handling,  only  limited 
processing  power  and  core  memory  capacity  were  needed.  A 
lower  cost  processor  with  4K-words  of  memory  and  unit  cost 
of  $15,000  was  replaced  by  a  minimum  configuration  UYK-20 
with  8K-words  of  memory  and  unit  cost  of  $24,000.  Another 
project  reported  a  four  to  five  month  slip  and  $4  00,000  to 
$500,000  cost  to  reprogram  with  C&S-2M,  the  standard 
high-level  language. 

The  trade-off  for  those  projects  was  to  lower 
life-cycle  costs  through  savings  in  ILS  costs,  training 
costs,  etc.  as  previously  discussed.  Unfortunately,  the 
immediate  concern  was  always  initial  acquisition  cost, 
schedule,  and  performance.  While  life-cycle  cost  was  given 
lip-service,  a  project's  success  was  ultimately  measured  by 
success  in  those  three  areas.  Thus,  imposition  of  the 
standard  on  a  system  well  into  development  impacted  directly 
on  the  measure  of  the  project's  success. 

Because  of  the  necessity  to  identify  firm 
requirements  for  UYK-20  production  units,  and  to  obtain  OSMN 
funds  through  the  surcharge  scheme,  NAVELEX  was  forced  to 
require  those  projects  to  switch  to  UYK-20. 

The  technical  drawback  of  adopting  a  standard  was 
that   the   UYK-20   might   not   be   specifically  suited  for  a 


68 


particular  application.  An  example  might  be  an  engine 
monitoring  and  control  system  where  a  powerful  bit 
manipulation  capability  was  needed.  That  project  would  be 
reguired  to  use  UYK-20  regard-less  of  the  minimal  bit 
manipulation  capability.  Interestingly,  no  project 
personnel  found  the  UJK-20  totally  unsuited  for  their 
application.  It  has  been  reported  that  as  of  mid- 1976  over 
100  projects  were  utilizing  OYK-20.  Tasks  included  the 
following  diverse  sorts  of  requirements: 

*  Message  Processing  Systems 

■  Low  memory  capacity  (8K-  to  16K-words) 

■  Low  computing  power 

■  High  I/O  capacity  (12  to  16  channels) 

■  High  data  rates 

*  Navigational  Systems 

•  Medium  memory  capacity  (16K-  to  32K-words) 

■  32-bit  (double  word)  I/O  transfer 

■  32-bit  data  manipulation 

■  Floating-point  trigonometric  and  hyperbolic 
functions 

■  High  accuracy  (up  to  24-bits  per  data  word 
preferred) 

■  Low  I/O  capacity  (4  to  8  channels) 

*  Signal  Analysis  Systems 

■  Large  storage  capacity  (65K-words  of  memory  plus 
high-speed  mass  storage  device  (disk)  on  DMA 
channel 

■  Multi-programming  capability 

■  Powerful  mathematical  capability 

■  High  throughput  (instruction  execution  rate) 

■  High  I/O  data  rates 

m   High  I/O  capacity  (8  to  16  channels) 

*  Target  Tracking  and  Fire  Control  Systems 

■  32K-  to  65K-words  of  storage  capacity 
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■  12  to  16  I/O  channels 

■  Mass  storage  device  (disk)  on  DMA  channel 

■  Floating-point  and  trigonometric  functions 

■  High  throughput  (instruction  execution  rate) 

■  Special   user   functions   implemented    through 
Microgrowth 

It  was  a  significant  accomplishment,  and  spoke  well  for  the 
DRG  specification,  that  JYK-20  was  able  to  handle  those  and 
many  other  diverse  tasks. 

The  conclusion  was  that  few  projects  were  severely 
impacted  by  imposition  of  a  standard  minicomputer. 
Unfortunately,  that  statement  could  not  be  made  about 
UYK-20,  the  computer  that  became  the  standard. 

2-   Hardware/Firmware  Capabilities 

Users  generally  found  the  UYK-20  architecture 
powerful  enough  for  their  needs.  Local  Jumps,  Load  Multiple 
and  Store  Multiple  instructions  not  common  on  minicomputers 
were  very  useful.  The  availability  of  32  general  registers 
was  a  powerful  programming  aid.  I/O  structure  was  versatile 
and  powerful  with  the  processor  independent  IOC.  Certain 
attributes  caused  some  inconvenience,  however. 

The  awkward  byte  addressing  scheme  discussed  in  the 
previous  section  would  add  an  additional  instruction  to  byte 
manipulation  operations  in  order  to  set  the  upper/lower  byte 
indicator.  Execution  time  for  the  byte  operation  would  be 
increased  about  50%  and  program  storage  requirements 
doubled.  One  solution  was  to  write  self-modifying  code,  to 
modify  the  byte  manipulation  instructions  "on-the-f ly". 
This  created  programs  which  were  very  hard  to  debug.  Also, 
such  code  was  non- reentrant ;  i.e.  it  could  not  be  reused 
without  reloading  the  original  program  from  an  external 
device,  and  it  could  not  be  shared  in  a  multi-programming 
environment. 

Lack  of  memory-to-memory  instructions  added  Load  and 
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Store  instructions  to  those  operations  because  of  the  need 
to  put  the  data  in  registers.  About  1.5  usee  was  added  to 
the  execution  time  for  memory-to-memory  operations,  and 
program  storage  requirements  were  tripled.  Lack  of  a  Test 
and  Set  instruction  (that  operation  required  two 
instructions  in  UYK-20)  could  cause  major  problems.  If  an 
interrupt  occurred  between  the  two  instructions,  which 
changed  the  value  that  was  being  tested,  then  the  test 
already  performed  was  invalid.  The  routine  executing  the 
Test  and  Set  instructions  would  not  be  aware  of  the  change 
and  would  proceed  on  the  basis  of  the  original  test  results 
when  the  interrupt  finished  processing.  The  solution  was  to 
lockout  interrupts  before  executing  the  Test  and  Set 
instructions  and  to  restore  interrupts  after  completing  the 
Test  and  Set.  That  solution  added  two  to  four  instructions 
and  3.3  to  4.8  usee  to  a  Test  and  Set  operation. 

There  were  no  absolute  compare  instructions  in 
UYK-20.  When  comparing  two  words,  the  most  significant  bit 
would  always  be  considered  the  sign.  To  compare  a  16-bit 
absolute  word  a  double-word  operation  was  needed.  Time  and 
storage  requirements  were  thus  again  added  to  the  user 
program. 

The  sum  total  of  those  sorts  of  deficiencies 
significantly  decreased  throughput  and  increased  storage 
requirements.  The  solution  was  to  implement  the  missing 
capabilities  in  the  User  Hicrogrowth  area  of  control  memory. 
Such  a  development  effort  had  to  be  user  funded,  however. 
As  an  example,  one  activity  received  a  quotation  of  $50,000 
to  implement  four  instructions  in  Microgrowth: 

*  Increment  and  Store  Memory 

*  Literal  Add  to  Memory 

*  Add  to  Memory 

*  Literal  Store  to  Memory 
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In  addition,  an  extra  $1,000  was  added  to  the  price  of  each 
production  unit.  Many  projects  preferred  to  suffer  the 
inconvenience  rather  than  pay  the  price. 

For  those  systems  with  large  storage  requirements 
and  a  large  number  of  tasks  which  could  be  performed 
simultaneously,  the  lack  of  proper  tools  to  implement 
multi-programming  was  a  serious  drawback.  Although  page 
registers  existed,  there  was  no  privileged  instructions  or 
memory  protection  with  which  to  implement  sophisticated  page 
swapping  algorithms.  The  alternatives  required  more  time 
and  tied  up  valuable  storage  space,  both  expensive 
commodities  in  time-critical,  real-time  applications. 

The  storage  capacity  problem  could  have  been 
relieved  in  some  cases  if  a  provision  to  expand  memory 
beyond  65K-words  had  existed.  Alternatives  involved  adding 
additional  OYK-201 s  to  the  system,  which  was  expensive  if 
the  additional  processing  power  was  not  also  needed,  or 
adding  a  mass  storage  device  on  the  DMA  channel,  which  would 
often  not  meet  speed  requirements.  To  solve  the  dilemma  in 
one  case,  a  semiconductor  memory  disk  emulator  was  conceived 
which  would  interface  to  the  computer  through  the  DMA 
channel.  Ability  to  utilize  semiconductor  memory  in  place 
of  core  memory  would  have  alleviated  some  similar  problems 
if  that  capability  had  existed. 

A  capacity  problem  also  plagued  some  projects  in  the 
I/O  area.  Although  the  processor  independent  IOC  provided 
powerful  I/O  capabilities,  only  16  channels  were  available, 
with  the  type  configuration  constraints  previously 
discussed.  To  get  more  capacity  required  multiplexing  on  a 
channel,  which  slowed  down  th  data  rate,  or  adding  more 
0YK-20's  to  the  system. 

Certain  I/O  configurations  would  have  benefited  from 
complete  independence  of  the  two  sides  of  a  duplex  channel. 
However,  both  sides  shared  registers  and  could  not  be 
cleared  independently.  Several  users  stated  the  need  to 
write  extra  routines  to  prevent  losing  data  on  one   side   if 
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the  need  arose  to  clear  the  other  side  of  a  channel. 

A  characteristic  of  serial,  synchronous  interface 
channels  was  that  the  first  few  characters  transmitted  were 
"garbage"  due  to  the  need  to  establish  synchronization. 
This  situation  could  not  be  tolerated  on  a  radio  (RF)  data 
channel  where  good  data  would  be  lost.  The  solution  was  to 
alter  the  RF  Data  Channel  hardware. 

A  common  complaint  from  development  programmers  was 
the  inadeguacy  of  the  Maintenance  Panel  for  software 
debugging.  Lack  of  I/O  status  indicators  and 
multiple-register  displays  were  cited  as  drawbacks.  The 
maintenance  panel  had  too  much  capability  for  hardware 
troubleshooting,  but  not  enough  for  program  debug.  A 
solution  would  have  been  to  reduce  the  capability  of  the 
maintenance  panel  and  provide  a  plug-in  software  debug 
panel.  The  lack  of  I/O  status  indicators  was  a  serious 
problem  since,  with  the  IOC  independent  of  the  processor, 
there  was  no  way  to  determine  if  an  I/O  transfer  was 
actually  taking  place  after  it  was  initiated. 

Lack  of  interrupt  nesting  capability  was  a  major 
concern  to  development  programmers.  Care  had  to  be 
exercised  so  that  multiple  interrupts  occuring  in  one  class 
would  not  store  over  the  original  machine  status,  thus 
preventing  a  return  to  the  interrupted  routine.  The 
solution  was  usually  to  lock-out  other  interrupts,  which 
virtually  nullified  the  priority  interrupt  capability. 
Real-time  programs  were  generally  interrupt  driven,  thus, 
loss  of  priority  interrupt  capability  was  a  serious 
drawback. 

The  awkwardness  of  using  the  indirect  addressing 
capability  caused  some  programmers  to  abandon  its  use  in 
favor  of  direct  addressing  with  indexing. 

3.   Availability  of  Support  Software 

The  support  software  for  the  AN/UYK-20  DPS  was  slow 
in  coming.    Those   programs   in   development  in  late-1973. 
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which  were  forced  to  switch  to  UYK-20,  had  only  a  limited 
capability  assembler.  As  a  result,  many  created  their  own 
program  development  capability.  Doing  that  added  to  the 
time  and  cost  of  a  system  since  operational  program 
development  would  cease  while  programmers  wrote  monitors, 
assemblers,  editors,  debug  routines,  etc.  As  an  example, 
the  cost  of  developing  an  assembler  was  $5,000  to  $100,000 
depending  on  its  capability.  It  was  cheaper  and  faster  to 
write  your  own,  however,  than  to  wait  for  the  Level  I  and 
Level  II  systems  to  be  released  and  debugged. 

The  late  delivery  of  CMS-2M  (early- 1975)  caused 
two-fold  problems.  Many  early  operational  programs  for 
UYK-20  had  to  be  written  in  assembly  language.  Since  it 
took  the  same  time  for  a  programmer  to  code  one  line  of 
assembly  language  as  to  code  one  line  of  a  high-level 
language  (with  a  ratio  of  about  six  assembly  language 
instructions  to  one  high-level  language  instruction) ,  the 
cost  was  significant.  Those  projects  which  elected  to  start 
development  with  another  high-level  language  (usually 
FORTRAN)  faced  the  prospect  of  reprogramming  in  CMS-2M  when 
that  compiler  became  available. 

The  whole  question  of  program  development  facilities 
for  a  minicomputer  is  worth  some  discussion.  It  was 
generally  not  possible  to  configure  a  small  computer  for 
efficient  program  development.  Level  II  Operating  System, 
which  was  self- hosted  on  the  UYK-20,  could  support,  only  one 
programmer  at  a  time.  Although  both  interactive  and  batch 
mode's  were  provided,  compile  times  were  slow  and  debug 
facilities  were  minimal.  What  was  generally  needed  was  a 
larger  computer  with  a  time-sharing  monitor  so  that  several 
programmers  could  work  simultaneously.  An  ideal  system 
would  feature  cross-assemblers  and  compilers  to  generate 
object  code  for  the  small  computer.  Adequate  memory,  disk 
storage  and  a  number  of  program  development  aids  such  as  a 
text  editor,  debug  utilities,  data  conversion  routines,  etc. 
would   be   a   necessity.    A   program   to   emulate  the  small 
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computer  would  be  useful  for  initial  debugging  of 
operational  software. 

A  few  activities  which  were  to  do  extensive  program 
development  for  the  UYK-20  did  create  such  systems.  The 
Electromagnetic  Systems  Laboratory  in  Sunnyvale  set  up  a 
time-sharing  system  on  a  Hewlett  Packard  3000  computer.  The 
system  featured  a  direct  link  to  a  UYK-20  computer  via  a 
special  intercomputer  1/3  channel.  Source  code  generated  on 
the  HP3000  could  be  loaded  directly  into  the  UYK-20  for 
assembly  or  compiling.  The  Autonetics  Division  of  North 
American  Rockwell  set  up  a  similar  system  based  on  a 
PDP-11/45  computer.  FCDSSA  San  Diego  developed  the 
CMS-2Y(20)  compiler  for  use  on  an  AN/OYK-7  computer  under 
the  SHARE/7  time-sharing  system  as  an  aid  to  their  software 
development  and  maintenance  efforts. 

Such  systems  were  understandably  costly  to  set  up. 
In  addition,  the  hardware  and  associated  software  to 
interface  the  system  directly  to  a  UYK-20  had  to  be 
developed  in-house.  The  project  sponsoring  the  development 
had  to  provide  the  funds.  The  dilemma  facing  the  project 
manager  was  whether  it  was  more  cost  effective  to  fund  a 
program  development  facility  or  to  provide  a  self-hosted 
system  for  the  UYK-20  and  suffer  the  inefficiencies.  As  an 
example,  the  price  of  a  self-hosted  system  with  Level  II  and 
CMS-2M  would  be  about  $150,000  including  peripherals.  At 
the  other  end  of  the  price  spectrum,  the  UYK-7  hosted  system 
would  cost  about  $800,000.  Commercial  systems  would  be 
priced  in  between  depending  on  capability. 

To  provide  program  development  facilities  and  save 
projects  the  cost  of  support  software  and  peripherals,  a 
System  Design  Laboratory  (SDL)  was  conceived  by  the  Naval 
Electronics  Laboratory  Center.  That  was  a  commercial 
computer  based  time-sharing  system  with  cross-assemblers, 
compilers  and  an  emulator  for  UYK-20.  The  system  could  be 
accessed  via  the  ARPANET,  a  commercial  nationwide  computer 
network   linked   by   leased   telephone   lines.    Anticipated 
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drawbacks  of  that  scheme  were  possible  demand  beyond  the 
system  capacity,  and  the  fact  that  classified  programs  could 
not  be  developed  on  the  system.  In  fact,  the  majority  of 
projects  depended  on  the  self-hosted  system.  The 
non-availability  of  a  well-tested,  complete,  self-hosted 
program  development  system  at  the  outset  impacted 
significantly  on  both  cost  and  schedule  of  projects. 

<l.   Support  Software  Capabilities 

It  is  beyond  the  scope  of  this  thesis  to  present  a 
detailed  analysis  of  the  impact  of  support  software 
capabilities  on  program  development.  However,  certain 
points  brought  out  by  development  programmers  are  worth  some 
discussion. 

A  dynamic  debug  capability  was  needed  under  Level 
II.  As  of  mid-1976  the  development  of  this  capability  was 
planned,  but  funds  were  not  available.  Dynamic  debug 
capability  would  allow  programmers  to  perform  analysis  on  an 
executing  program  without  interfering  with  its  execution. 

CMS-2M  listings  of  source  code  and  object  code  were 
not  produced  side-by~side,  making  cross-referencing  awkward 
and  time  consuming. 

CMS-2H  depended  on  the  trigonometric  and  hyperbolic 
functions  provided  through  MATHPAC.  Accuracy  provided  was 
insufficient  in  some  applications.  The  large  variety  of 
useful  functions  and  routines  developed  for  a  well-used 
language  like  FORTRAN  were  not  available  with  CMS-2M. 
Because  that  language  anticipated  restricted  usage,  such  a 
library  of  routines  would  never  be  created,  forcing  the 
development  programmer  to  write  his  own  routines  when 
needed.  In  recognition  of  this  problem,  the  User's  Group 
Software  Directory  and  the  Software  Repository  mentioned  in 
Chapter  III  were  an  attempt  to  prevent  redundant  development 
of  such  routines. 

CMS-2M  was  not  aa  optimizing  compiler.  Because  many 
operational   programs  are   time-critical   and   have   large 
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storage  requirements,  it  would  have  been  useful  to  have  an 
optimizing  version  of  the  CMS-2M  compiler  to  minimize  use  of 
those  assets. 

Like  any  general  purpose  real-time  executive, 
SDEX-20  required  too  much  core  and  system  overhead  (time 
spent  in  executing  the  executive  software)  to  be  widely 
useful.  Those  applications  with  time-critical  routines  and 
large  storage  requirements  were  forced  to  write  their  own 
real-time  monitors.  By  writing  an  executive  in-house  it 
could  be  optimized  for  the  particular  application,  thus 
minimizing  storage  and  overhead.  Many  programmers  felt  that 
a  general  purpose  real-time  executive  would  be  useful  if  the 
source  code  were  available  to  programmers  as  a  reference  to 
aid  in  writing  their  own.  The  low  usage  of  SDEX-20  raised 
the  question  of  the  cost-effectiveness  of  supplying  that 
type  of  support  software. 

5-   Availability  of  Peripherals 

The  peripherals  problem  is  actually  divided  into  two 
catagories:  peripherals  for  program  development,  and 
peripherals  for  tactical  systems.  Up  to  mid- 1976  no 
standard  militarized  peripherals  were  available  for 
purchase,  except  keyboard/printers  and  paper  tape 
reader/punches  which  had  been  in  existance  for  several 
years.  Those  units  ware  generally  too  large  for  a 
minicomputer  installation.  Even  with  the  introduction  of 
the  Alphanumeric  Display  Device  (ADD)  and  the  Cartridge 
Magnetic  Tape  Unit  (CMTO)  in  mid-1976,  important  peripherals 
were  still  lacking,  such  as  a  magnetic  tape  unit 
(reel-to-reel) ,  a  disk  storage  device,  and  a  graphics 
display  terminal.  Projects  were  forced  to  fund 
militarizaiori  of  their  own  peripherals,  which  created  the 
same  sort  of  proliferation  problem  encountared  with 
minicomputers  in  the  early  1970' s. 

During  the  early  production  period  in  late-1973, 
only   UNIVAC  peripherals  could  be  interfaced  with  the  OYK-20 
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for  program  development.  Those  peripherals  were  generally 
too  large  and  expensive  for  a  minicomputer  system,  so 
projects  began  acquiring  their  own.  Costs  of  procuring 
peripherals  included  development  of  device  software  modules 
to  interface  with  the  UYK-20  operating  systems.  The 
acquisition  of  peripherals  to  be  used  for  program 
development  was  costly,  especially  since  those  peripherals 
would  in  general  not  be  used  in  the  tactical  system  itself. 
Projects  were  wise  to  retain  a  OYK-20  system  with 
peripherals  configured  for  program  development  to  be 
provided  as  Government  Furnished  Equipment  (GFE)  for  future 
development  efforts. 

6«     Hardware    and    Software    Reliability    and 
Maintainability 

The  acute  quality  and  reliability  problems 
experienced  in  the  AN/OYK-20  DPS  were  reported  in  Chapter 
III.  It  was  those  problems  that  had  the  most  profound 
impact  on  user  development  efforts. 

The  programs  developing  in  mid-to-late- 1 973  were 
forced  to  use  Functional  Demonstration  Models  (FDMfs)  and 
Advanced  Production  Engineering  Models  (APE's)  in  order  to 
meet  development  schedules.  That  hardware  was  essentially 
not  ready  for  release.  The  numerous  deficiencies  and 
failures  caused  significant  down  time.  Projects  were  forced 
to  purchase  two  computers  and  cannabilize  one  to  keep  the 
other  running.  Early  production  units  had  similar  problems. 
Software  debugging  on  faulty  hardware  was  a  difficult  and 
time-consuming  task.  One  activity  reported  expending  three 
man-months  of  labor  trying  to  debug  a  program  when  the 
problem  was  actually  in  the  interrupt  hardware. 

Efforts  to  troubleshoot  faulty  hardware  were 
hampered  by  faulty  spares  in  the  spare  parts  kits.  The  kits 
were  expensive  ($13,000  each)  so  that  project  managers  were 
unwilling  to  purchase  sufficient  numbers.  Project  personnel 
estimated  that  one  spares  kit  per  computer  was  necessary   to 
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ensure  parts  availability.  Memory  Array  Boards,  which 
experienced  very  high  failure  rates,  were  repairable  modules 
and  were  not  included  in  the  spares  kits.  Since  the  time  to 
ship  the  repairable  modules  back  to  ONIVAC  for  repair  and 
return  was  running  six  to  eight  weeks,  activities  were 
forced  to  purchase  extra  Memory  Array  Boards  (at  $1,300 
each)  to  minimize  down  time. 

It  was  more  timely  and  cost  effective  for  some 
activities,  like  NESEC  San  Diego,  to  do  their  own  hardware 
trouble-shooting  and  repair,  rather  than  call  in  ONIVAC 
engineers.  The  diagnostic  software  and  documentation  was 
not  well  suited  to  this  effort.  The  diagnostic  routines 
could  isolate  circuit  board  failures,  but  not  design 
problems  which  plagued  the  earlier  machines.  Activities 
turned  to  logic  circuit  diagrams,  but  found  that  those  also 
contained  errors.  It  was  difficult  to  maintain  accurate 
up-to-date  files  of  logic  circuit  diagrams  since  no  formal 
system  existed  for  procuring  them. 

Early  releases  of  the  support  software  had  many 
errors.  User  activities  attempting  to  debug  the  software 
were  hampered  by  inadequate  and  erroneous  documentation. 
Source  code  was  not  available  initially  to  aid  in  their 
efforts.  After  repeated  demands  the  source  code  for  the 
operating  systems  was  made  available,  but  coda  for  the 
compilers  was  withheld  as  a  matter  of  proprietary 
information.  Most  software  engineers  interviewed  expressed 
the  opinion  that  the  support  software  source  code,  including 
compilers,  should  be  purchased  outright  by  the  Navy  so  that 
it  could  be  made  available  to  users.  That  was  especially 
true  when  the  support  software  contained  so  many  errors  and 
the  documentation  was  inadequate.  In  many  cases  programmers 
had  to  resort  to  the  source  code  to  determine  the  details  of 
system  software  operation.  One  activity  reported  that  it 
was  once  forced  to  reprogram  to  take  advantage  of  an 
assembler  capability  which  was  not  mentioned  in  the 
documentation.   A  basic  problem  with  software  documentation 
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was  that  no  detailed  discussions  of  software  philosophy  were 
presented.  Adding  the  problems  in  the  software  on  top  of 
problems  in  the  hardware  made  an  extremely  difficult 
situation  for  programmers  attempting  to  debug  operational 
software. 

7.   Lack  of  Dedicated  Appropriated  Funds  to  Support  the 
AN/0YK-2C  DPS 

It  is  significant  that  a  majority  of  problems  were 
corrected  when  usage  was  sufficient  to  isolate  those 
problems.  Given  time  the  support  software  became  available. 
Given  time  the  standard  peripherals  would  be  available.  If 
NAVELEX  could  have  waited  until  the  system  was  adequately 
tested  before  release,  much  of  the  inconvenience  caused  to 
users  would  have  been  eliminated.  The  reason  that  NAVELEX 
could  not  wait  was  lack  of  funding.  It  was  necessary  to 
identify  specific  requirements  for  production  units  and  to 
receive  orders  for  the  system  in  order  to  get  the  surcharge 
that  paid  for  project  support.  NAVELEX  was  thus  forced  to 
require  the  use  of  the  system  before  it  was  ready.  An 
obvious  solution  was  to  wait  until  funding  for  the  entire 
acquisition  cycle  was  reasonably  assured  (another  year  at 
best) .  Then  wait  until  the  system  was  complete,  including 
software  and  testing,  before  releasing  it  (another  two  to 
three  years) .  Of  course,  a  three  to  four  year  delay  would 
have  brought  prolif eratioa  of  minicomputer  types  in  the  Navy 
inventory  to  an  unacceptable  level.  Some  of  that  delay 
might  have  been  saved  by  purchasing  a  "market-tested" 
computer  system,  then  militarizing  it.  At  least  the 
reliable  commercial  equivalent  would  have  been  available  for 
use  in  development  until  the  militarized  version  was 
available.  Certainly  computer  systems  existed  which  could 
meet  Navy  performance  requirements. 

The  lack  of  dedicated  funds  has  thus  been  identified 
as  the  prime-mover  in  many  events  in  the  history  of  the 
AN/UYK-20  DPS  acquisition.   The  final  chapter  will  summarize 


80 


and  present  some  recommendations  which  might  prove  useful  in 
future  tactical  processor  acquisitions. 
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V.   SUMMARY,  CONCLUSIONS  AND  RECOMMENDATIONS 

In  1972,  when  proliferation  of  minicomputer  types  in  the 
Navy  inventory  was  perceived  to  be  a  significant  problem, 
the  Tactical  Digital  Systems  Office  (TADSO)  of  the  Naval 
Material  Command  (NAVMAT)  conceived  the  procurement  of  a 
standard  minicomputer.  Use  of  that  minicomputer  was 
reguired  in  all  tactical  systems  reguiring  a  small  computer 
unless  sufficient  justification  was  given  to  use  a  different 
computer. 

Although  no  funds  had  been  appropriated  for  such  a 
procurement,  NAVMAT,  with  the  approval  of  the  Chief  of  Naval 
Operations  (CNO) ,  proceeded  to  initiate  the  procurement 
action  by  reprogramming  a  minimum  of  Research,  Development, 
Test  and  Evaluation  Navy  (RDTSEN)  appropriated  funds  from 
anticipated  user  projects.  A  Design  Review  Group  (DRG)  was 
convened,  and  a  fairly  restrictive  technical  specification 
was  drawn  up.  With  the  exception  of  an  assembler,  support 
software  reguirements  were  missing  entirely  from  the 
specification.  At  that  point  the  Navy  was  procuring 
one-half  of  a  minicomputer  system  with  no  funds  appropriated 
for  future  support.  The  necessity  to  get  support  funds 
forced  NAVMAT  to  reguire  projects  still  in  their  development 
phase  to  include  the  standard  minicomputer  immediately  in 
their  program  and  to  assess  a  surcharge  on  purchases  of 
standard  minicomputer  hardware  and  software. 

The  contract  award  went  to  the  lowest  bidder,  UNIVAC 
Defense  Systems  Division  of  Sperry-Rand  Corporation.  The 
DRG  specification  appeared  to  be  influenced  by  the  UNIVAC 
design  philosophy,  owing  to  the  large  number  of  UNIVAC 
computers  in  the  Navy  inventory. 

Although  the  original  acguisition  strategy  intended  that 
the   minicomputer   system   be   a   militarized   off-the-shelf 
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commercial  system,  UNI7AC  won  the  competition  with  a  new 
design  that  had  never  been  in  production  and  was  not  upward 
compatible  with  any  well-established  family  of  computers. 

In  order  to  meet  user  project  development  schedules,  the 
first  Functional  Development  Models  (FDM)  (non-militarized 
prototypes)  were  delivered  within  120  days  after  contract 
award  and  the  first  Advanced  Production  Engineering  Models 
(APE)  (militarized  prototypes)  within  nine  months  after 
contract  award.  Although  the  hardware  design  held  the 
potential  for  good  capabilities  in  a  minicomputer,  the 
FDMfs,  APE's  and  early  production  units  were  inadequately 
tested  and  debugged.  Reliability  was  very  low  and 
maintainability  suffered  from  inadequate  diagnostic 
programs,  poor  documentation,  faulty  spares,  and  excessive 
turnaround  time  on  repairable  modules. 

Initially  software  was  non-existent;  when  released  it 
was  inadequately  tested  and  debugged.  User  efforts  to  use 
the  software  were  hampered  by  poor  documentation. 

Thus,  lack  of  dedicated  funding  forced  users  to  utilize 
the  standard  minicomputer  as  a  system  component  before  it 
was  ready.  The  result  was  significant  labor  costs  to  cope 
with  the  problems  and  increased  risks  in  the  development  of 
operational  programs. 

It  was  mid-1976,  three  years  after  contract  award, 
before  the  system  was  sufficiently  reliable  and  possessed 
adequate  support  software  to  be  considered  a  viable  system 
component  in  a  developing  tactical  system. 

It  must  be  recognized  that  follow-on  standard  tactical 
digital  processors  may  not  be  minicomputers.  Perhaps  the 
design  will  be  a  distributed  microprocessor  system  or  some 
architecture  not  yet  conceived.  The  rapid  advance  in  the 
state-of-the-art  of  digital  processors  makes  the 
possibilities  endless.  The  events  connected  with  the 
standard  minicomputer  acguisition  do  foster,  however,  some 
conclusions  and  recommendations  pertinent  to  future 
acquisitions  of  tactical  digital  processors,   regardless   of 
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architectural  philosophy. 

1«  The  life-cycle  cost  and  logistics  support 
considerations  make  adoption  of  standards  necessary. 

2.  The  decision  as  to  how  often  to  reprocure  a  standard 
involves  a  tradeoff  between  two  alternatives:  (1) 
reprocuring  rapidly  enough  to  keep  up  with  advances  in  the 
state-of-the-art,  and  (2)  producing  a  particular  standard 
long  enough  to  maximize  the  economic  benefit  of  large-scale 
production.  The  tolerance  of  tactical  system  development 
engineers  for  using  an  "old"  standard  must  also  be  taken 
into  account.  That  decision  must  be  made  on  the  basis  of 
factors  such  as  availability  of  funds  and  how  well  the 
current  standard  is  performing  at  the  time. 

3.  The  primary  goal  of  the  standard  minicomputer 
acquisition  strategy  was  to  stem  the  proliferation  of 
minicomputer  types  in  the  Navy  inventory.  That  goal  was 
accomplished  at  the  expense  of  significant  adverse  impact  on 
the  costs  and  schedule  of  user  projects.  It  is  this 
authors  opinion  that  the  "cost"  of  the  adverse  impact 
outweighed  the  benefit  of  minimizing  proliferation.  It 
should  be  the  primary  goal  of  future  tactical  digital 
processor  acquisitions  to  deliver  a  highly  reliable  system 
complete  with  support  software  and  accurate  documentation. 
That  would  be  simply  applying  current  systems  engineering 
management  and  Integrated  Logistics  Support  policies. 

4.  The  standard  minicomputer  procurement  was  totally 
dependent  on  user  projects  for  both  development  and 
operational  support  funding.  That  fact  was  the  underlying 
reason  why  projects  were  forced  to  use  the  system  before  it 
was  ready,  accounting  for  most  of  the  events  which  impacted 
adversely  on  those  user  projects.  The  availability  of  both 
RDT&EN  and  OSMN  funding   for   a   standard   tactical   digital 
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processor  acquisition  should  be  reasonably  assured  prior  to 
contract  award.  Based  on  experience  with  the  standard 
minicomputer  acquisition,  contract  award  should  be  planned 
for  two  to  three  years  prior  to  required  delivery  of  the 
militarized  version  to  the  fleet. 

5.  Since  it  would  be  desirable  to  minimize  the  time 
between  contract  award  and  delivery  to  the  fleet,  the 
acquisition  strateqy  should  stronqly  consider  procurement  of 
an  off-the-shelf,  market-tested  system  which  exhibits  a 
strong  heritage  from  a  successful  family  of  processors. 
Availability  of  software  should  be  a  major  consideration. 
It  is  this  author's  opinion  that  the  strong  competition  in 
the  digital  equipment  industry  assures  that  new  commercial 
systems  push  the  state-of-the-art  while  at  the  same  time 
exhibiting  reliable  hardware  and  software  performance.  The 
strategy  just  suggested  should  thus  suffer  minimal  risk  of 
early  obsolescence.  This  strategy  would  also  insure  the 
immediate  availability  of  FDM's  for  use  in  development. 

6.  Award  of  contract  in  the  standard  minicomputer 
procurement  was  based  on  two  factors,  (1)  technical 
responsiveness  and  (2)  lowest  price  proposal.  Such  a 
strategy  precludes  consideration  of  which  proposal  presents 
the  best  reliability  and  performance  for  the  price.  Future 
acquisition  strategies  should  require  a  fully  negotiated 
procurement  based  on  a  performance  specification.  Such  a 
strategy  would  give  the  Source  Selection  Evaluation  Board 
the  flexibility  to  consider  both  design  and  price. 
Proposals  offering  market-tested  systems  could  be  weighted 
heavily  since  such  systems  have  usage  data  to  prove 
reliability  and  performance. 

7.  Despite  the  fact  that  a  pre-award  survey  found  all 
companies  submitting  proposals  to  be  responsive,  the  winner 
experienced  immediate  and  severe  quality  assuranca  problems. 
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Those  QA  problems  had  a  profound  impact  on  user  development 
efforts.  Future  pre-award  surveys  should  firmly  establish 
the  potential  contractors1  abilities  to  produce  a  reliable 
product.  Careful  evaluation  of  quality  control  standards 
should  be  made  to  assure  that  those  standards  will  insure 
delivery  of  a  reliable  product. 

8.  The  Requirements,  Indefinite  Delivery  contract  awarded 
in  the  standard  minicomputer  acquisition  was.  well-suited  as 
a  production  contract  and  should  be  utilized  in  future 
procurements  of  standard  equipment. 

9.  The  imposition  of  military  specifications  on  a 
commercial  design  creates  some  risk  in  the  development  area. 
Future  acquisition  strategy  should  consider  awarding  a  cost 
type  development  contract  for  the  militarization  effort. 
Funds  permitting,  the  award  of  such  a  contract  to  several 
companies  would  permit  a  "fly-off",  ensuring  competition  for 
the  production  contract. 

10.  As  tactical  digital  processors  become  smaller  due  to 
advances  in  Large  Scale  Integration  techniques,  the  need  for 
non-self-hosted  program  development  facilities  becomes  more 
important.  Future  acquisitions  of  tactical  digital 
processors  should  consider  award  of  a  separate  fixed-price 
contract  for  a  program  development  system  to  support  the 
standard  digital  processor.  Certain  digital  equipment 
companies  specialize  in  design,  integration,  and  production 
of  such  specialized  systems  from  off-the-shelf  components, 
so  that  adequate  competition  should  exist  for  such  a 
procurement. 

11.  The  maintenance  and  control  panels  on  the  AN/UYK-20 
computer  did  not  provide  adequate  capabilities  for  software 
test  and  debug.  Future  systems  should  include  a  plug-in 
software  debug  console  to  provide  this  capability. 
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12.  A  generalized  real-time  executive  may  occupy  too  much 
core,  and  require  too  much  system  overhead  to  be  widely 
useful  in  a  tactical  system  environment.  Such  software 
could  be  better  optimized  in  designs  tailored  for  the 
specific  application.  Future  acquisitions  should  not 
include  a  standard  real-time  executive  with  the  support 
software,  but  should  provide  some  means  (such  as  the 
Software  Repository)  by  which  projects  are  made  aware  of 
such  software  developed  by  other  users. 

13.  Software  development  engineers  interviewed  stated  that 
source  code  for  the  various  support  software,  including 
assemblers  and  compilers,  was  a  useful  tool  to  aid  in 
debugging  operational  programs.  Knowledge  of  the  source 
code  would  allow  the  developer  to  determine  the  exact 
operation  of  the  software  and  the  philosophy  behind  its 
design.  Future  acquisition  strategies  should  include 
outright  purchase  of  the  data  rights  to  all  software  as  well 
as  hardware  so  that  source  code  may  be  supplied  to  users. 
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APPENDIX  A 


AN/UYK-7  SYSTEM  DESCRIPTION 


Manufacturer 

Construction  Standard 

Maximum  Physical  Dimensions 

Maximum  Weight 

Maximum  Power  Consumption 

Architecture 

Word  Size 

No.  of  Registers 

Inst.  Execution  Time 

Add/Sub/Load 

Multiply 

Divide 
Micro programmable 
Technology 
Privileged  State 
Stack 

Main  Memory 

Maximum  Size 

Speed 

Word-size 

Memory  Parity  Checking 

Memory  Write  Protect 

Technology 

Multiported 

Instruction  Set 

Double  Precision 
Byte  Manipulation 
Bit  Manipulation 
Floating  Point 
Math/Trig  Functions 
Negation 

Arithmetic  Complement 
Stack  Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging  Hardware 


DNIVAC 

MIL-E-16400 

4  1"Hx24"Dx20"W 

527  to  1,139  lbs. 

1,720  to  6,000  watts 

32-bits 

8  or  16  (accumulators) 

6.5  usee 

10.0  usee 

17.0  usee 

No 

Third  Generation/MSI 

Yes 

No 


256K-words  (16K/module) 

1 . 5  usee 

32-bits 

No 

Yes 

Magnetic  Core 

8  ports/16K  module 


Yes 

Yes 

Yes 

Hardware 

Software 

One's  Complement 

One's   Complement 

No 


262K-words 

flulti-level 

7    or    14    index    registers 

No 
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I/O  Controller 

No.  of  Channels 
Types  of  Channels 
Maximum  Data  Rate 
Processor  Independent 

Maintenance/Control  Panel 
Location 
Multi-register  displays 

Initial  Program  Load 

Reliability  &  Maintainability 
MTBF 
MTTR 
Diagnostic  Programs 

Modular  Building  Blocks 

Support  Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug  Routines 
Operating  Systems 
Real-Time  OS 

Interrupts 

Priority  Structure 
Nesting  Capability 


16 

Serial/Parallel 
167,000  words/sec 
Yes 


Remote 
No 

Firmware 


Unknown 

15  minutes 

Firmware/Software 

Yes 


Yes 

FORTRAN/CMS-2 

Yes 

Yes 

Yes 

Yes 

SHARE/7 

Yes 


Yes 
No 
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APPENDIX  B 


STANDARD  MINICOMPUTER  SPECIFICATIONS 


Manufacturer 

Construction  Standard 

Maximum  Physical  Dimensions 

Maximum  Weight 

Maximum  Power  Consumption 

Architecture 

Word  Size 

No.    of    Registers 

Inst.  Execution  Time 

Add/Sub/Load 

Multiply 

Divide 
Microprogrammable 
Technology 
Privileged  State 
Stack 

Main  Memory 

Maximum  Size 

Speed 

Word-size 

Memory  Parity  Checking 

Memory  Write  Protect 

Technology 

Multiported 

Instruction  Set 

Double  Precision 
Byte  Manipulation 
Bit  Manipulation 
Floating  Point 
Math/Trig  Functions 
Negation 

Arithmetic  Complement 
Stack  Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging  Hardware 


MIL-E-16400 
26"Hx24"Dx19"W 
220  lbs. 
1,000  watts 


16-bits  minimum 
4  expandable  to  16 

1.2  usee 

9.0  usee 

20.0  usee 

Yes 

3rd  generation/MSI 

Not  reg'd 

Not  req'd 


(general) 


65K-words  (8K  min.) 

1.2  usee  ff . 0  usee 

16^bits  minimum 

Optional 

Not  req'd 

RAM,  non-volatile 

Two  (Processor/IOC) 


effective) 


Yes 

Yes 

Not 

Not 

Not 

One's 

One's 

No 


req'd 

reg  •  d 

req'd 

and  Two's  Complement 
or  Two's  Complement 


65K-words 
To  at  least 
All  general 
Yes 


one  level 
registers 
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I/O  Controller 

No.  of  Channels  16 

Types  of  Channels  Ser/Par/DMA 

Maximum  Data  Sate  19 OK- words/sec 

Processor  Independent  Yes 

Maintenance/Control  Panel 

Location  Optional 
Multi-register  displays   Not  req'd 

Initial  Program  Load  Hardware  or  Firmware 

Reliability  &  Maintainability 

MTBF  2000  hours 

MTTR  15  minutes 

Diagnostic  Programs  Yes 

Modular  Building  Blocks  Yes 

Support  Software 

Assemblers  Yes 

Compilers  Not  req'd 

Loader  Not  req'd 

Editor  Not  req'd 

Librarian  Not  req'd 

Debug  Routines  Not  req'd 

Operating  Systems  Not  req'd 

Real-Time  OS  Not  req'd 

Interrupts 

Priority  Structure  Yes 

Nesting  Capability  Four  levels-one  per  group 
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APPENDIX  C 


CP-642B  SYSTEM  DESCRIPTION 


Manufacturer 

Construction  Standard 

Maximum  Physical  Dimensions 

Maximum  Height 

Maximum  Power  Consumption 

Architecture 

Word  Size 

No.  of  Registers 

Inst.  Execution  Time 

Add/Sub/Load 

Multiply 

Divide 
Microprogrammable 
Technology 
Privileged  State 
Stack 

Main  Memory 

Maximum  Size 

Speed 

Word-size 

Memory  Parity  Checking 

Memory  Write  Protect 

Technology 

Multiported 

Instruction  Set 

Double  Precision 
Byte  Manipulation 
Bit  Manipulation 
Floating  Point 
Math/Trig  Functions 
Negation 

Arithmetic  Complement 
Stack  Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging  Hardware 


DNIVAC 
MIL-E-16400 
72"Hx37,,Dx38"W 
2,400  lbs. 
2,000  watts 


30-bits 

3  (accumulators) 

8-12  usee 

8-12  usee 

8-12  usee 

No 

Discrete  Components 

No 

No 


32K  to  262K-words 

4  usee 

32-bit 

No 

No 

Magnetic  Core 

No 


Yes 

Yes 

No 

Software  Implementad 

Software  Implemented 

One's  Complement 

One's  Complement 

No 


32K-words 
No 

7  Index  Registers 
No 
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I/O  Controller 

No.  of  Channels  16 

Types  of  Channels  Parallel 

Maximum  Data  Hate  Unknown 

Processor  Independent  No 

Maintenance/Control  Panel 

Location  Front  of  Cabinet 
Multi-register  displays   Yes 

Initial  Program  Load  Firmware 

Reliability  &   Maintainability 

MTBF  1500  hours 

MTTR  Unknown 

Diagnostic  Programs  Yes 

Modular  Building  Blocks  No 

Support  Software 

Assemblers  Yes 

Compilers  CS-1 

Loader  Yes 

Editor  Yes 

Librarian  Yes 

Debug  Routines  Yes 

Operating  Systems  No 

Real-Time  OS  No 

Interrupts 

Priority  Structure  Yes 

Nesting  Capability  No 
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APPENDIX  D 


AN/UYK-15(V)  SYSTEM  DESCRIPTION 


Manufacturer 

Construction  Standard 

Maximum  Physical  Dimensions 

Maximum  Weight 

Maximum  Power  Consumption 

Architecture 

Word  Size 

No.  of  Registers 

Inst.  Execution  Time 

Add/Sub/Load 

Multiply 

Divide 
Micr ©programmable 
Technology 
Privileged  State 
Stack 

Main  Memory 

Maximum  Size 

Speed 

Word-size 

Memory  Parity  Checking 

Memory  Write  Protect 

Technology 

Multiported 

Instruction  Set 

Double  Precision 
Byte  Manipulation 
Bit  Manipulation 
Floating  Point 
Math/Trig  Functions 
Negation 

Arithmetic  Complement 
Stack  Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging  Hardware 


ONIVAC 

MIL-E-16400 

2  1"Hx17"Dx19"W 

200  lbs. 

500  watts 

16-bits 

64  (general) 

0.75  usee 

3.8  usee 

3.8  usee 

No 

Third  Generation/MSI 

No 

No 


65K-words 

0.75  usee 

18-bits 

Yes 

Yes 

Magnetic  Core 

Four  ports/16K-word  bank 


Yes 

Yes 

Yes 

Software  Implemented 

Hardware  Implemented 

Two's  and  One's  Complement 

Two's  Complement 

No 


65K-words 

No 

All  General  Registers 

No 
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I/O  Controller 

No.  of  Channels 
Types  of  Channels 
Maximum  Data  Rate 
Processor  Independent 

Maintenance/Control  Panel 
Location 
Multi-register  displays 

Initial  Program  Load 

Reliability  &  Maintainability 
MTBF 
MTTR 
Diagnostic  Programs 

Modular  Building  Blocks 

Support  Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug  Routines 
Operating  Systems 
Real-Time  OS 

Interrupts 

Priority  Structure 
Nesting  Capability 


16 

Ser/Par 

190K-words/sec 

Yes 


Front  of  Cabinet 
No 

Firmware 


2000  hours 
15  minutes 
Firmware/Software 

Yes 


Yes 

Unknown 

Yes 

Unknown 

Unknown 

Unknown 

Unknown 

Unknown 


Yes 

Four  levels-one  per  class 
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APPENDIX  E 


CP-890  SYSTEM  DESCRIPTION 


Manufacturer 

Construction  Standard 

Maximum  Physical  Dimensions 

Maximum  Weight 

Maximum  Power  Consumption 

Architecture 

Word  Size 

No.  of  Registers 

Inst.  Execution  Time 

Add/Sub/Load 

Multiply 

Divide 
Microprogrammable 
Technology 
Privileged  State 
Stack 

Main  Memory 

Maximum  Size 

Speed 

Wor  d—size 

Memory  Parity  Checking 

Memory  Write  Protect 

Technology 

Multiported 

Instruction  Set 

Double  Precision 
Byte  Manipulation 
Bit  Manipulation 
Floating  Point 
Math/Trig  Functions 
Negation 

Arithmetic  Complement 
Stack  Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging  Hardware 


ONIVAC 
MIL-E-16400 
74"Hx18"Dx22"W 
700  lbs. 
1,675  watts 

30-bits 

2  (accumulators) 

1.8  usee 

8.8  usee 

15.0  usee 

No 

2nd  Generation/Discrete 

Yes 

No 


32K-words 

1.0  usee 

32-bits 

Yes 

Yes 

Magnetic  Core 

No 


Yes 

Yes 

No 

Hardware  Implemented 

Software  Implemented 

One's    Complement 

One's  Complement 

No 


32K-words 

Multi-level 

7  Index  Registers 

No 
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I/O  Controller 

No.  of  Channels 
Types  of  Channels 
Maximum  Data  Rate 
Processor  Independent 

Maintenance/Control  Panel 
Location 
Multi-register  displays 

Initial  Program  Load 

Reliability  &   Maintainability 
MTBF 
MTTR 
Diagnostic  Programs 

Modular  Building  Blocks 

Support  Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug  Routines 
Operating  Systems 
Real-Time  OS 

Interrupts 

Priority  Structure 
Nesting  Capability 


16 

Parallel 
Unknown 
Yes 


Front  of  Cabinet 
Yes 


Software 


2000  hours 
30  minutes 
Firmware/Software 

Yes 


Yes 

Unknown 

Yes 

Unknown 

Unknown 

Unknown 

Unknown 

Unknown 


Yes 

Four-one  per  class 
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APPENDIX  F 


AN/UYK-12(V)  SYSTEM  DESCRIPTION 


Manufacturer 

Construction  Standard 

Maximum  Physical  Dimensions 

Maximum  Weight 

Maximum  Power  Consumption 

Architecture 

Word  Size 

No.  of  Registers 

Inst.  Execution  Time 

Add/Sub/Load 

Multiply 

Divide 
Mic reprogrammable 
Technology 
Privileged  State 
Stack 

Main  Memory 

Maximum  Size 

Speed 

Word-size 

Memory  Parity  Checking 

Memory  Write  Protect 

Technology 

Multiported 

Instruction  Set 

Double  Precision 
Byte  Manipulation 
Bit  Manipulation 
Floating  Point 
Math/Trig  Functions 
Negation 

Arithmetic  Complement 
Stack  Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging  Hardware 


Rolm  Corporation 
MIL-E-5400 
7.6"Hx10. 1"Dx12.5"W 
60  lbs. 
275  watts 


16-bits 

4  (accumulators) 

5.9  usee 

9.7  usee 

9.7  usee 

No 

3rd  Generation/MSI 

No 

No 


4K  expandable  to  32K 

1.0  usee 

16-bits 

No 

No 

Magnetic  Core 

No 


Yes 

Yes 

Yes 

Software  Implemented 

Software   Implemented 

One's   Complement 

Two's   Complement 

No 


1,024  words 

Multi-level 

Two  accumulators 

Yes 
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I/O  Controller 

No.  of  Channels 
Types  of  Channels 
Maximum  Data  Rate 
Processor  Independent 

Maintenance/Control  Panel 
Location 
Multi-register  displays 

Initial  Program  Load 

Reliability  &   Maintainability 
MTBF 
MTTR 
Diagnostic  Programs 

Modular  Building  Blocks 

Support  Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug  Routines 
Operating  Systems 
Real-Time  OS 

Interrupts 

Priority  Structure 
Nesting  Capability 


61  devices  on  I/O  bus 

Ser/Par 

600K-words/sec 

Yes 


Attached  or  Remote 
No 


Firmware 


11,000  hours 
28.6  minutes 
Software 

For  memory  &   I/O 


Yes 

FORTRAN/BASIC/ALGOL 

Yes 

Yes 

Yes 

Yes 

Batch/Disk 

Disk 


Yes 

Yes 
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APPENDIX  G 


DESCRIPTION  OF  SYSTEM  SOFTWARE 


Level  0  Operating  System 

*  Equipment  Configuration 

■  ONIVAC  1108  hosted 

*  System  Routines 

■  AN/DYK-20  Simulator 

■  Macro-Assembler 

■  System  Generator 

■  FORTRAN  Cross-Compiler 

■  CMS-2M  Cross-Compiler 

■  Transfer  Utilities 

*  Written   in  FORTRAN  IV  except  for  the  macro-assembler 
which  is  written  in  UNIVAC  1108  assembly  language. 

L^l^I  I  Operating  System 

*  Equipment  Configuration 

>   AN/DYK-20 (V)       hosted       (a      minimum   of    24K-words  of 
memory    required) 

■  Paper  Tape  Reader/Punch  (required) 

■  Keyboard/Printer  (required) 

•  Op  to  four  Magnetic  Tape  Units  (optional) 

■  Line  Printer  (optional) 

■  Card  Reader/Punch  (optional) 

*  System  Routines 

■  Core-Resident     Routines    (interactive    system 
controller,  I/O  controller) 
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■  Text  Editor  (edits  source  code) 

■  Linking-Loader  Subsystem  (loads  relocatable 
object  code  into  memory) 

■  Debug  Dtility  system  (memory  inspect  and  change, 
absolute  core  dump  or  load,  absolute  correction 
load,  snapshot  dump,  memory  search  and  constant 
storage) 

■  System  Tape  Generator 

■  Basic  Assembler  (generates  relocatable  object 
code  -  no  macro  capability) 

*  Written  in  FORTRAN  17 


Level  II  Operating  System 

*  Equipment  Configuration 

■  AN/OIK- 20 (V)  hosted  (minimum  65K-words  of  core 
memory  required) 

■  Keyboard/Printer  (required) 

■  Card  Reader/Punch  (required) 

■  Four  Magnetic  Tape  Units  (required) 

*  System  Routines 

■  Core-Resident  Routines  (system  controller,  I/O 
controller,  batch  monitor) 

■  ULTRA-16  Macro-Assembler  (generates  relocatable 
object  code) 

■  CMS-2M  Compiler 

a  FORTRAN  IV  Compiler 

■  Linking  Loader  (loads  relocatable  object  code) 

■  Debug  Utilities  (memory  inspect  and  change, 
memory  dump,  absolute  core  dump  or  load,  absolute 
correction  load,  snap-shot  dump,  memory  search, 
and  constant  storage) 

■  Conversion  Subroutines  (ASCII  decimal  integer  to 
binary  integer  and  vv.,  ASCII  characters  to  field 
data   characters   and   vv.,  ASCII  octal  to  binary 
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integer  and  vv.) 

■  General    Utilities    (transfer   data   from  one 
peripheral  device  to  another) 

■  Librarian   (edit   and  update   user  source  code, 
i 

object  code  and  absolute  code) 

■  System  Tape  Generator 

■  Disk  File  Manager 

CMS-2M  Compiler 

*  CMS-2M  language  is  a  subset  of  CMS-2,  the  standard 
Navy  high-level  language  for  tactical  applications. 

*  Produces  relocatable  object  code  for  the  AN/UYK-20 
computer. 

*  Equipment  Configuration 

■  Host  Computer 

■  Card  Header/Punch 

■  Line  Printer 

■  Four  Magnetic  Tape  Units 

*  Host  Computers 

■  AN/UYK-20 (V)  with  Level  II  Operating  System 

■  UNIVAC  1108 

■  IBM  360/370 

■  CDC  6600/6700 

*  Incorporates  capabilities  for  both  scientific 
calculation  and  data  management. 

*  Uses  familiar  English  words  and  algebraic  expressions 
to  define  and  describe  logical  operations  and  data 
manipulations. 

*  Components 

■  Lexical  Analyser  -  prepares  source  code  input  for 
translation 

■  Syntax  Analyser  -   translates   source   code   into 
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intermediate   language   and   generates   error 
messages. 

■  Direct  Code  Processor  -  translates  direct  code 
into  intermediate  language 

■  Code  Generator  -  translates  intermediate  language 
code  into  relocatable  object  code 

■  Output  Editor  -  produces  hardcopy  listings 

Machine  Independent  System  Generator 

*  Produces  system  tapes  for  AN/UYK-20  (V)  from  object 
files  produced  on  host  machines 

*  Host  Machines 

■  ONIVAC  1108 

■  CDC  6600/6700 

SDSX-20  Real-Time  Executive 

*  Peripheral  suite  as  specified  by  the  user 

*  Building  block  modules  provide  basic  computer  program 
management  functions  upon  which  the  user  builds  his 
operational  programs 

■  Initialization  Routines 

■  Scheduling  Routines 

■  Interrupt  Management  Routines 

■  I/O  Management  Routines 

■  Error  Management  Routines 

CMS-2Y(20)  Compiler 

*  AN/UYK-7  Computer  with  SHARE/7  Operating  System 

*  Components 

■  UYK-20  Code  Generator 

■  ULTRA/16  Assembler 
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■  UYK-7  hosted  Loader 

■  UYK-20  Simulator/Debug  Tool 

*  Features 

■  Interfaces  with  CMS-2Y  (7)   Librarian  for   source 
code  editing 

■  Extensive  Optimization 

■  Produces  side-by-side  source   code/object  code 
listings 
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APPENDIX  H 


AN/UYK-20(V)  DPS  DESCRIPTION 


Manufacturer 

Construction  Standard 

Maximum  Physical  Dimensions 

Maximum  Weight 

Maximum  Power  Consumption 

Architecture 

Word  Size 

No.  of  Registers 

Inst.  Execution  Time 

Add/Sub/Load 

Multiply 

Divide 
Mic reprogrammable 
Technology 
Privileged  State 
Stack 

Main  Memory 

Maximum  Size 

Speed 

Word-size 

Memory  Parity  Checking 

Memory  Write  Protect 

Technology 

Multiported 

Instruction  Set 

Double  Precision 
Byte  Manipulation 
Bit  Manipulation 
Floating  Point 
Math/Trig  Functions 
Negation 

Arithmetic  Complement 
Stack  Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging  Hardware 


UNIVAC 

MIL-E-16400 

18.6»Hx24.0"Dx17.5"W 

185  lbs. 

900  watts 


16-bits 
16  or  32 


(general) 


0.75  usee 

3.8  usee 
usee 

(512  word  growth) 
generation/MSI 


6.8 

Yes 

3rd 

No 

No 


65K-words 

0.75  usee  effective 

16-bits 

No 

No 

Magnetic  Core  RAM 

Two  (CP/IOC  and  DMA) 


Yes 

Load/Index/Store/Com  pare 

Limited 

Yes 

Yes 

One's  and  Two's  Complement 

Two's  Complement 

No 


65K-words 

Multi-level 

All  general    registers 

64    page    address   registers 
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I/O  Controller 

No.  of  Channels 
Types  of  Channels 
Maximum  Data  Bate 
Processor  Independent 

Maintenance/Control  Panel 
Location 
Multi-register  displays 

Initial  Program  Load 

Reliability  &   Maintainability 
MTBF 
MTTR 
Diagnostic  Programs 

Modular  Building  Blocks 

Support  Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug  Routines 
Operating  Systems 
Real-Time  OS 

Interrupts 

Priority  structure 
Nesting  Capability 


16  full  duplex 
Serial/Parallel/DMA 
190K-word  per  sec 
Yes 


Inside  front  cover 
No 

192-word  Read-Only-Memory 


1500  demonstrated 
15  minutes  specified 
Firmware/Software 

Yes 


ULTRA/16,  MACRO-20 

FORTRAN,  CMS-2M 

Yes 

Yes 

Yes 

Yes 

Levels  0,  I,  II 

SDEX-20 


Yes-three  classes 
Limited-one  per  class 
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APPENDIX  I 
BASIC  AN/UYK-20  HARDWARE  CONFIGURATION  AND  OPTIONS 

Basic  Configuration 

*  Microprogrammed  Processor 

*  Input/Output  Controller 

*  16  General  Registers 

*  Bootstrap   ROM  -   two   programs   for  channels   and 
peripheral  devices  selected  by  the  user 

*  8K-words  of  Core  Memory 

*  Power  Supply  as  specified  by  the  user: 

■  Single  phase,  115  volts,  60  or  400  hertz 

■  Three  phase  delta,  115  volts,  60  or  400  hertz 

■  Three  phase  wye,  208  volts,  60  or  400  hertz 

*  Four   Input/Output   Channels  (one  group)  as  specified 
by  the  user: 

■  MIL-STD-188C  Synchronous  (0  to  9600  baud) 

•  MIL-STD-188C  Asynchronous  (four  rates  of  75,  150, 
300,  600,  1200,  or  2400  baud) 

■  RS-232C  Synchronous  (0  to  9600  baud) 

a  RS-232C  Asynchronous  (four  rates  of  75,  150,  300, 
600,  1200,  or  2400  baud) 

■  NTDS    Slow,   Fast,   and   ANEW   in   a   normal   or 
intercomputer  mode 

Options  Available 

*  8K-word  Memory  Modules  (up  to  65K-words) 
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*  Additional  16  General  Registers 

*  Direct  Memory  Access  (DMA)  capability 

*  MATHPAC  Modules 

*  Microgrowth  Card 

*  Special  Tools  Kit 

*  Spare  Parts  Kit  (one  year  supply) 

*  Different  Bootstrap  Cards 

*  Dp   to   16   I/O   channels   in   four   channel  groups 
options  as  specified  above  plus: 

■  NTDS  Serial  (32-bit) 

■  Dual  Channel  NTDS  (32-bit) 

*  Engineering  Services 

*  Training  Courses 
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APPENDIX  J 


ROLM  1602  SYSTEM  DESCRIPTION 


Manufacturer 

Construction  Standard 

Maximum  Physical  Dimensions 

Maximum  Height 

Maximum  Power  Consumption 

Architecture 

Word  Size 

No.  of  Registers 

Inst.  Execution  Time 

Add/Sub/Load 

Multiply 

Divide 
Microprogrammable 
Technology 
Privileged  State 
Stack 

Main  Memory 

Maximum  Size 

Speed 

Word-size 

Memory  Parity  Checking 

Memory  Write  Protect 

Technology 

Multiported 

Instruction  Set 

Double  Precision 
Byte  Manipulation 
Bit  Manipulation 
Floating  Point 
Math/Trig  Functions 
Negation 

Arithmetic  Complement 
Stack  Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging  Hardware 


Rolm  Corporation 
MIL-E-5400/16400 
7.6"Hx10. 1"Dx12.5»W 
100  lbs. 
350  watts 


16-bits 

4  (accumulators) 

1.0  usee 

5.3  usee 

q  ix    usee 

Yes  (3.5K-words  growth) 

3rd  generation/MSI/LSI 

No 

Yes 


65K-words 

1 .0  usee 

16-bits 

No 

No 

Core  or  Semiconductor 

Two  (CP/DMA) 


Yes 

No 

Yes 

Yes 

Firmware 

Two's  Complement 

Two§s  Complement 

Yes- 


1,024  words 

Multi-level 

Two  accumulators 

Yes 
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I/O  Controller 

No.  of  Channels 
Types  of  Channels 
Maximum  Data  Rate 
Processor  Independent 

Maintenance/Control  Panel 
Location 
Multi-register  displays 

Initial  Program  Load 

Reliability  5  Maintainability 
MTBF 
MTTR 
Diagnostic  Programs 

Modular  Building  Blocks 

Support  Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug  Routines 
Operating  Systems 
Real-Time  05 

Interrupts 

Priority  Structure 
Nesting  Capability 


61  devices  on  I/O  bus 
Serial/Parallel 
1,000K- words/sec 
DMA  only 


Attached  or  Remote 
No 


Firmware 


11,000  hours 
28.6  minutes 
Firmware/Software 

Yes 


Self-hosted  and  cross- 

BASIC/ALGOL/FORTRAN 

Yes 

Yes 

Yes 

Yes 

Disk-based 

Yes 


Yes 
Yes 
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APPENDIX  K 


HP2100A  SYSTEM  DESCRIPTION 


Manufacturer 

Construction  Standard 

Maximum  Physical  Dimensions 

Maximum  Weight 

Maximum  Power  Consumption 

Architecture 

Word  Size 

No.  of  Registers 

Inst.  Execution  Time 

Add/Sub/Load 

Multiply 

Divide 
Microprogrammable 
Technology 
Privileged  State 
Stack 

Main  Memory 

Maximum  Size 

Speed 

Word-size 

Memory  Parity  Checking 

Memory  Write  Protect 

Technology 

Multiported 

Instruction  Set 

Double  Precision 
Byte  Manipulation 
Bit  Manipulation 
Floating  Point 
Math/Trig  Functions 
Negation 

Arithmetic  Complement 
Stack  Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging  Hardware 


Hewlett  Packard 
Commercial 
12.3"Hx26.0"Dx16.8»W 
111  lbs. 
800  watts 


16-bits 

Two  (accumulators) 

1.96  usee 

10.7  usee 

16.7  usee 

Yes  (Writable  Control  Store) 

MSI/LSI 

No 

No 


32K-words 

0.98  usee 

17-bit 

Yes 

Yes 

Folded  Planar  Core 

Three  (CP/DMA-1/DMA-2) 


Load/Store  only 

No 

Yes 

Yes 

No 

One's  and  Two's  Complement 

Two's  Complement 

No 


2,048  words 

Multi-level 

No 

No 
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I/O  Controller 

No.  of  Channels 
Types  of  Channels 
Maximum  Data  Rate 
Processor  Independent 

Maintenance/Control  Panel 
Location 
Multi-register  displays 

Initial  Program  Load 

Reliability  &   Maintainability 
MTBF 
MTTR 
Diagnostic  Programs 

Modular  Building  Blocks 

Support  Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug  Routines 
Operating  Systems 
Real-Time  OS 

Interrupts 

Priority  Structure 
Nesting  Capability 


1U 

Serial/Parallel 
1, OOOK-words/sec 
DMA  only 


Front  of  chassis 
No 

Firmware 


Unknown 
Unknown 
Software 

Yes 


Yes 

FORTRAN/ALGOL/BASIC 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 


None 
None 
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APPENDIX  L 


DEC  PDP-11/45  SYSTEM  DESCRIPTION 


Manufacturer 

Construction  Standard 

Maximum  Physical  Dimensions 

Maximum  Weight 

Maximum  Power  Consumption 

Architecture 

Word  Size 

No.  of  Registers 

Inst.  Execution  Time 

Add/Sub/Load 

Multiply 

Divide 
Microprcgrammable 
Technology 
Privileged  State 
Stack 

Main  Memory 

Maximum  Size 

Speed 

Word-size 

Memory  Parity  Checking 

Memory  Write  Protect 

Technology 

Multiported 

Instruction  Set 

Double  Precision 
Byte  Manipulation 
Bit  Manipulation 
Floating  Point 
Math/Trig  Functions 
Negation 

Arithmetic  Complement 
Stack  Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging  Hardware 


Digital  Equipment  Corporation 

Commercial 

71.5"Hx30.0"Dx21.7"W 

300  lbs. 

2,300  watts 


16-bit  (18-bit  addresses) 
16  (general) 

0.3  usee 
3.3  usee 
7.5  usee 
No 

MSI/LSI 

Two  -  Kernal  &   Supervisor 

Yes 


128K-words 

0.3  to  0.98  usee 

16-bit  (18-bit  for  parity) 

Yes 

Yes 

Cor e/MOS/Bi polar 

Single  -  UNIBUS  structure 


Yes 

Yes 

Yes 

Yes 

Software 

One's  or  Two's  Complement 

Two's  Complement 

Yes 


256K-bytes 

Yes 

All  general  registers 

Yes 
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I/O  Controller 

No.  of  Channels 
Types  of  Channels 
Maximum  Data  Rate 
Processor  Independent 

Maintenance/Control  Panel 
Location 
Multi-register  displays 

Initial  Program  Load 

Reliability  8  Maintainability 
MTBF 
MTTR 
Diagnostic  Programs 

Modular  Building  Blocks 

Support  Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug  Routines 
Operating  Systems 
Real-Time  OS 

Interrupts 

Priority  Structure 
Nesting  Capability 


Multiplexed  ONIBOS 
Serial/Parallel 
2,500K-words/sec 
Yes 


Front  of  chassis 
Yes 


Software 


Unknown 
Unknown 
Software 

Yes 


Yes 

BASIC/FORTRAN/C 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 


Yes 
Yes 
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APPENDIX  H 


VARIAN-73  SYSTEM  DESCRIPTION 


Manufacturer 

Construction  Standard 

Maximum  Physical  Dimensions 

Maximum  Weight 

Maximum  Power  Consumption 

Architecture 

Word  Size 

No.  of  Registers 

Inst.  Execution  Time 

Add/Sub/Load 

Multiply 

Divide 
Microprogrammable 
Technology 
Privileged  State 
Stack 

Main  Memory 

Maximum  Size 

Speed 

Word-size 

Memory  Parity  Checking 

Memory  Write  Protect 

Technology 

Multiported 

Instruction  Set 

Double  Precision 
Byte  Manipulation 
Bit  Manipulation 
Floating  Point 
Math/Trig  Functions 
Negation 

Arithmetic  Complement 
Stack  Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging  Hardware 


Varian  Data  Machines 
Commercial 
14"Hx20.5"Dx19"W 
120  lbs. 
900  watts 


16-bit 

16  (general) 

0.66  usee  (MOS) 

4.95  usee  (MOS) 

5.61  usee  (MOS) 

Yes  (Writable  Control  Store) 

MSI/LSI 

No 

No 


usee  (Core) 


262K-words 

.33  usee  (MOS)/. 66 

16-bit 

Yes 

Yes 

MOS/Core 

Two  (CP/DMA) 


Yes 

No 

No 

Software 

Software 

One's   or   Two's  Complement 

Two's   Complement 

No 


2K-words 

Multi-level 

Yes 

Yes 
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I/O  Controller 

No.  of  Channels 
Types  of  Channels 
Maximum  Data  Rate 
Processor  Independent 

Maintenance/Control  Panel 
Location 
Multi-register  displays 

Initial  Program  Load 

Reliability  S  Maintainability 
MTBF 
MTTR 
Diagnostic  Programs 

Modular  Building  Blocks 

Support  Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug  Routines 
Operating  Systems 
Real-Time  OS 

Interrupts 

Priority  Structure 
Nesting  Capability 


Multiplexed  I/O  Bus 
Serial/Parallel 
3,030K-words/sec 
DMA  only 


Front  of  chassis 
No 

Firmware 


Unknown 
Unknown 
Software 

Yes 


Yes 

BASIC/FORTRAN/RPG 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 


Yes 
No 
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